Linux-kernel mailing list archive 1998-10,: Re: mmap() versus read()

# Re: mmap() versus read()

Erik Corry (erik@arbat.com)
Mon, 9 Mar 1998 08:33:50 +0100 (MET)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: k552wc: "(no subject)"
- Previous message: Juergen Kreileder: "Re: [PATCH] 2.1.88 Hanging Processes (Uninterruptible Sleep)"

In article <199803090215.CAA154158@out2.ibm.net> you wrote:
> : I just perused the solaris madvise() man page and I don't think it would
> : help apache in the long run. Specifically:
> :
> : MADV_SEQUENTIAL
> : Tells the system that addresses in this range are
> : likely to be accessed only once, so the system will
> : free the resources mapping the address range as quickly
> : as possible.

> If I remember correctly from my SunOS kernel hacking days, this call
> doesn't do much.

for madvise (WILLNEED and DONTNEED) are very useful indeed.

> Anyway, this call never worked very well in SunOS and I doubt they have
> fixed it in Solaris. I'd be interested in hearing if someone can come
> up with a test program that shows different behavior with and w/o the
> madvise.

I can, if you're interested, but with the above advice constants,
not with MADV_SEQUENTIAL.

> I made the call largely redundant, in UFS, by putting in automatic
> free behind for sequential accesses. This was a huge hack and a huge
> win. The idea was this:

> . the file system eeps track of sequential access in the inode
> (almost all file systems do this for read ahead).

> . the file system "knows" when the VM system is going to start
> being starved for memory and start paging stuff out.

> . on large (>256K 6 years ago, probably .5M or 1M today) files

Probably dependent on RAM size.

> that are being accessed sequentially, the file system looks at
> free memory on each page in request, if it is close (within
> about 1M or so) to being all used up, the file system looks
> backwards a "windows" worth (say .25M) and frees up the pages
> behind.

> The effect is that memory fills up with whatever and then when large I/O
> happens, the OS just slides a .5M window through the file.

Sounds very cool.

    --
    Erik Corry erik@arbat.com

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

- Next message: k552wc: "(no subject)"
- Previous message: Juergen Kreileder: "Re: [PATCH] 2.1.88 Hanging Processes (Uninterruptible Sleep)"