Messages in this thread | | | Date | Mon, 9 Mar 1998 00:05:31 +0100 | From | Erik Corry <> | Subject | Re: mmap() versus read() |
| |
On Sun, Mar 08, 1998 at 11:06:23PM +0100, MOLNAR Ingo wrote: > > > On Sun, 8 Mar 1998, Hans Reiser wrote: > > > I disagree. If you page fault more than once, so as to establish a > > pattern of sequentiality, you are already losing compared to madvise(). > > not if the (autodetected) access pattern is persistant, eg. you save the > pattern into the filesystem itself ... this is IMO better than madvise(),
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 MADV_NORMAL MADV_SEQUENTIAL MADV_RANDOM MADV_WILLNEED MADV_DONTNEED
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 majordomo@vger.rutgers.edu
| |