[lkml]   [1998]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: mmap() versus read()
    I just perused the solaris madvise() man page and I don't think it would
    help apache in the long run. Specifically:

    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.


    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

     \ /
      Last update: 2005-03-22 13:41    [W:0.020 / U:108.820 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site