. madvise(.. SEQUENTIAL ..) and madvise(.. RANDOM ..) don't do
much in SunOS (in fact, I think they do nothing). Unless
things have changed in Solaris, that's still true.
. madvise(.. WILLNEED ..) may have done prefetches but I don't think
so, I'm pretty sure it was left in as a hook in case they needed
it in the future.
. madvise(fd, off, length, WONTNEED) turns into a
VOP_PUTPAGE(vp, off, length, ...) which throws the pages away.
The WONTNEED one is useful to applications that have better knowledge than
the OS can figure out.
I personally would love to see a real implementation of WILLNEED in
Linux. Think of what it could do for apache or mh. You open up a
directory, map every file, do a WILLNEED (which means the OS starts
brining in those pages), and then start accessing the pages. The
effect should be a disk request queue length of Nfiles * filesize(i).
Long queue lengths are better for performance these days. Most disks
spin fast enough that the dominating term is the seek/rotational delay,
so you want a long queue length so you have something to optimize.
If someone wants to talk about how you could do this, again, I'd be
happy to help out with some thoughts. I have a sorta idea how I'd
do it in SunOS but not a great idea of how it would work in Linux.
The real problem is this: can a process put a request in the disk
queue and then return from system all, leaving the OS to finish it up?
The anser should be yes, it should be the same could path that read
ahead logic uses. Unfortunately, that coe path is frequently a mess.
I have'nt looked into how linux does that (shame on me).
--lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu