MADV_SEQUENTIAL
Tells the system that addresses in this range are
likely to be accessed only once, so the system will
free the resources mapping the address range as quickly
as possible.
In apache-1.3 we still use the multiple process model, and so an mmap() is
only in use by a single process at a time. If multiple requests are
active on the same file there are multiple mmap()s for the file. This is
a bit of a waste... but there's not much we can do until we go
multithreaded. In this case madvise() is perfect because each task gets
to say "I'm using it sequentially" and then do something sequentially
In the future with threads, or even with 1.3 if you use the experimental
mod_mmap_static, there will be an mmap() cache. In this case multiple
processes/threads are sharing the same mmap()d memory... and "sequential"
doesn't really describe its usage very well. It's more like "multiple
sequential readers". And the description above doesn't quite sound right.
Note that even if linux gets a sendfile/TranmitFile syscall the mmap()
case is still important -- specifically for mmap()d databases. We're
designing a copy-avoiding I/O layer for apache-2.0 and support for
non-filesystem objects is on the list; as is support for sendfile... it's
all vapourware at the moment though.
Dean
On Sun, 8 Mar 1998, 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(),
> 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).
>
> thus madvise() might even turn out to be an overhead, on a sufficiently
> smart kernel and/or on sufficiently smart hardware.
>
> -- mingo
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu