> 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