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()
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

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