Messages in this thread | | | Date | Mon, 9 Mar 1998 10:55:55 +1100 | From | Richard Gooch <> | Subject | Re: mmap() versus read() |
| |
Erik Corry writes: > 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?
I agree with Erik. There are applications which will process the same data file in different orders, so a persistent madvise() is not appropriate in these situations. The syscall overhead is peanuts. It's more like 10 000 times faster than a disc seek. The syscall overhead is simply not worth considering.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |