lkml.org 
[lkml]   [1998]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mmap() is slower than read() on SCSI/IDE on 2.0 and 2.1
On Mon, Dec 14, 1998 at 05:43:21AM -0800, Jay Nordwick wrote:
> - When a binary executable image is mmap()ed to be run, wouldn't you want
> to prefetch blocks of code and data -- what would be the difference
> between this and the user mmap()ing in a file?

Note, Stephen Tweedie's latest "go faster VM stripes" do this, a bit.
I mean the aligned 64k clustering page-in.

> I don't really see the problem: some indecision on an arbitrary limit?
> This is the same thing as prefetching with read(), isn't it? You don't
> know how much to prefetch with read, do you? As a worst case, why not
> have the same semantics as read -- prefetch the next page if you have to
> sleep to read it -- not optimal, but at least will bring mmap() to the
> performance of read().

mmap() tends to be used more for random access, so you have to be a bit
more cautious with the heuristics. Ok, if you can spot when an mmap()
is being used in a regular way.

> I always thought that mmap() should be fast, especially when you use
> it for IPC.

It is fast, just not asynchronous. (Wild, hand-waving theorist
warning): You can get the full speed of readahead with the zero-copy of
mmap() by running several threads through the file at the same time,
each thread accessing different pages in some good order. Here's where
I wave my hands very hard...

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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