It's probably useful, but not a substitute for madvise. I
have very large files that are read in a surprising (to the
kernel) order, and often only read once. For this madvise
is essential. And using madvise to avoid trashing the
page cache with read-once files is next to impossible to
acheive any other way.
> since madvise() carries only very few information, and madvise() has no
> knowledge about the underlying block device, eg. you might be using a
> solid state disk with no seek cost (or a ramdisk).
For those without a Solaris manual page, here (from memory)
is the information that madvise lets you give:
madvise(caddr_t start, off_t length, int advice)
where advice is one of
Madvise tells the kernel what it is going to do with
the file. If the kernel has a device with essentially
zero seek cost it can choose to ignore the readahead
implications of madvise, but it might still use the
madvise DONTNEED calls to choose which pages to use when
it runs short.
> thus madvise() might even turn out to be an overhead, on a sufficiently
> smart kernel and/or on sufficiently smart hardware.
On suffciently smart hardware you can choose to ignore
madvise. Sure you still have a syscall overhead, but
what we gain is the ability to handle several otherwise
pathologically bad performance situations.
A smart kernel is a great goal, but sometimes the app
writer knows better than anyone what order the file is
going to be needed in. So why not let the app writer
tell the kernel what he knows? How many syscalls do
we get for a single unnecessary hard disk seek? 1000?
-- Erik Corry
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com