Messages in this thread | | | Date | Mon, 19 Jul 1999 23:42:43 +0200 | From | Jamie Lokier <> | Subject | Re: 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/
| |