Messages in this thread |  | | | Subject | Re: mmap() versus read() | | Date | Mon, 9 Mar 1998 08:33:50 +0100 (MET) | | From | (Erik Corry) | |
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.
From my tests on Solaris that's still true. However the other advices
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
|  |