lkml.org 
[lkml]   [1998]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.830 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site