> Hi,
>
> On Fri, 4 Dec 1998 15:02:56 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
>
> >> One odd thing about the readahead: you don't start the readahead until
> >> _after_ you have synchronously read in the first swap page of the
> >> cluster. Surely it is better to do the readahead first, so that you
> >> are submitting one IO to disk, not two?
>
> > This would severely suck when something else would be doing
> > a run_taskqueue(&tq_disk). It would mean that we'd read
> > n+1..n+15 before n itself.
>
> No, not at all. This is already the way we do all readahead
> everywhere in the kernel.
>
> The idea is to do readahead for all the data you want, *including* the
> bit you are going to need right away. Once that is done, you just
> wait for the IO to complete on that first item.
Indeed.
In the old time, swapping and paging were different things, but they seems
to be confused in Linux.
You may perform read-ahead when you really swap in a process that had been
swapped out. But about paging, you must consider that this mechanism is
not sequential but mostly ramdom in RL. So you just want to read more data
at the same time and near the location that faulted. Reading-ahead is
obviously candidate for this optimization, but reading behind must also be
considered in my opinion.
File read-ahead is based on the way that data file are often accessed
sequentially by applications and we have to detect this behaviour prior
to reading ahead large data blocks.
For mmapped file, you may want to allow applications to tell you as
they intend to access data and trust them. But for paging, you just
want to read more data than 1 single page at a time, assuming that
data near the faulted address have good chances to be accessed by
the application soon.
That's my current opinion on this topic.
Regards,
Gerard.
-
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/