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:11:07AM -0800, David S. Miller 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?
>
> Sure, but what is your limit to pre-faulting pages in? I tried this
> once and hit this very problem. FreeBSD and some other systems have a
> hard coded limit of the number of pages to do this for as a ceiling, I
> think this is not the answer.

I see a misunderstanding here. Jay refers to pre-fetching (from disk),
while Dave refers to pre-faulting (setting up page tables and waiting
for the page data to be present).

These are very different.

> The problematic case (and a real life one) is when all of libc has
> been faulted into main memory by various processes, when you start one
> up do you map in all of libc when it gets mmap'd by the application?
> If not, then which if any pages do you choose?

You don't map any more than you do know. What you _do_ do is readahead
pages into the page cache, based on when pages are mapped into the
process. If you just map the lot, (a) it's inefficient (as you know);
(b) you don't get told when to initiate further asynchronous readahead
_before_ the pages are needed synchronously.

Anyway, don't the latest VM clustered page-in/swap-in changes have some
of the sort of effect we're talking about? However, I don't think they
implement genuine predictive readahead, which could be done like this:

Process faults on page 0.
Kernel reads pages 0..15 into page cache (one cluster).
Kernel maps page 0 into process.
Process faults on page 1.
Kernel maps page 1 into process.
Process faults on page 2.
Kernel maps page 2 into process.
Process faults on page 3.
Kernel maps page 3 into process.
Process faults on page 4.
Kernel maps page 4 into process.
Process faults on page 5.
Kernel maps page 5 into process.
Process faults on page 6.
Kernel maps page 6 into process.
Process faults on page 7.
Kernel maps page 7 into process.
Process faults on page 8.
Kernel maps page 8 into process.
Kernel initiates asynchronous readahead of pages 16..31 (next cluster).
Process faults on page 9.
Kernel maps page 9 into process.
[Repeat until page 23]
Process faults on page 24
Kernel maps page 24 into process.
Kernel initiates asynchronous readahead of pages 32..47 (next cluster).

See the difference? This way, the process _never_ blocks waiting for data.
The existing heuristics don't have this property, as far as I know.

-- 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.052 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site