lkml.org 
[lkml]   [1999]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: clustering page-ins
Chuck Lever wrote:
> > If you ever get a situation where you've "nothing else to do", so you're
> > waiting for a page, your read-ahead strategy has already failed.
>
> i can think of several cases where that's not true. for instance, how
> about the first read of a file? somehow the OS has to find out that an
> application wants file data in the first place. should i add read-ahead to
> open() and mmap() ?

Yes, that's what I mean be failed. The "perfect" strategy knows you
want the data at open() time or even before. For most filesystems and
access patterns that's just _too_ difficult to predict. But Hans Reiser
claims that for sequential opens in a directory, reiserfs even manages
this quite often.

But we're not talking about that here, nor am I advocating it.

> what about truly random file accesses?

Granted, this is the example. I defy you to come up with a truly random
algorithm ;-) [Not just being anal -- I do think eventually we will be
able to analyse program codes and past statistical behaviour, and make
rather good predictions. But not yet.]

> read-ahead strategies are speculative and heuristic; they will never
> be perfect and we should not expect them to be.

Quite. But a common case is reading a file sequentially, and that can
be done perfectly (see definition).

> > Adding a check to the fast path slows down all page faults, but
> > eliminates waiting in the perfectly-predictable cases.
>
> as memory becomes more plentiful, how can we justify that trade-off?

Even if I had 4GB of memory I'd still find a use for my disks.

We're not talking about programs with a "working set" as such, we're
talking about those that do streamed, sequential access. Whether it's
serving http or playing an audio file or a video file, or just an
optimised `cp'.

There's the implicit assumption that those files are probably not in
cache. We know we can achieve the same performance _as if_ the files
are in cache for streaming apps, so why not?

> so essentially, your argument is that it's OK to slow down programs that
> can keep their entire working set in memory just so I/O bound programs can
> go a little faster?

Well if there was any measurable slow down I'd agree. But I don't think
the slow down will be measurable. See my suggested two-line
addition to the fast path.

> soft page faults are often filled by sharing a page, too. it doesn't seem
> worth it to check for read-ahead when the file is shared.

You don't check for read-ahead on every page. You do exactly the test I
gave, which has ultra-low impact in the common case.

> there is no wait in the no_cached_page branch, really. all the pages for
> the given cluster are requested from the disk, and in that process, their
> pages are added to the page cache if not already there. the wait occurs
> if the page still isn't up to date after all the read-ahead is done, but
> that happens in the mainline code.

Sorry, I confess I had not read the code properly.
I mean "how much time is spent waiting in wait_on_page?"
I think it could be zero, after the first few reads
have got read-ahead into a steady state for streaming.

> i think there is an assumption built-in to the design of read-ahead in
> Linux: that files accessed via read() are more likely to be sequentially
> accessed than files accessed via mmap().
> thus, the generic read stuff has more sophisticated read-ahead logic
> baked into it, and the filemap stuff is built more for random
> access. IMHO, this design is the right decision.

Yes it's good that read() was optimised first, no it's not good to leave
mmap() unoptimised, IMO.

A number of "highly optimised" streaming designs use mmap(). Things
like http servers, audio & video players. Unfortunately they currently
take a relative hit due to lack of asynchronous readahead, so the bright
ones leave it configurable. See also the work on rearranging ELF to
make read-ahead more effective.

mmap() has some fine features: (1) no copying, (2) the data isn't
duplicated, so you have more free memory for the page cache, (3) data
read by read() has to be written to swap when under memory pressure,
data read by mmap() does not. (2) and (3) should always lead to the
same or less I/O.

But the present situation means that read() is optimal sometimes because
it's faster, and mmap() is optimal at other times depending on your
precise memory configuration of the moment. It would be great if
exactly one method was optimal all the time.

> what you are suggesting is copying some of the read-ahead logic from
> generic_file_readahead into filemap_nopage, right? it might be reasonable
> to check more carefully in filemap_nopage that a file is being read
> sequentially.

Yes I'm basically talking about "asynchronous readahead" as done for
read(). But the logic needs to be different: as you've noticed, the
current heuristic is a too heavy to go in the soft fault path. And
generic_file_readahead is even more heavy.

> > I don't understand you here. You say the number of i/os should be
> > reduced, but the i/o count for non read-ahead is surely larger because
> > each page is read individually.
>
> quite the opposite. the goal of read-ahead is to prevent waiting for
> i/o, not to reduce the overall number of blocks read.

Terminology mismatch perhaps? I'm referring to the number of i/o
requests, not the number of blocks read. (I'm guessing) read-ahead will
tend to decrease the former while increasing the latter. I don't think
this is an important issue... we both agree that there's no point
reading more than necessary.

> however, as the number of extra pages read during read-ahead increases,
> the overall efficiency of the system as a whole drops, since reading extra
> pages lowers the maximum rate the OS can fulfill disk requests from
> applications.

On this I disagree. If a big disk read is not much slower than a small
disk read (i.e. a modern disk), but random head movement is slow, I'd
have thought the added clustering due to read-ahead would reduce the
total number of head movements when two applications are competing for
different areas of the disk.

I'm prepared to be wrong though.

-- 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:53    [W:0.098 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site