> 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. In this case, that
> means doing a readahead on pages n to n+15 inclusive, and then after
> that doing the synchronous read_swap_page on page n. The kernel will
> happily find that page in the swap cache, work out that IO is already
> in progress and wait for that page to become available.
>
> Even though the buffer IO request layer issues the entire sequential
> IO as one IO to the device drivers, the buffers and pages involved in
> the data transfer still get unlocked one by one as the IO completes.
> After submitting the initial IO you can wait for that first page to
> become unlocked without having to wait for the rest of the readahead
> IO to finish.
I find my previous reply to you mail very unclear. In fact, my idea is
to implemement something like the following:
Inputs:
-------
- faulted_address
- offset_behind offset behind the faulted address up to which we want
to swap-in data.
- offset_ahead offset ahead the faulted address ...
Strategy:
---------
- queue reads of all the pages between (faulted_address - offset_behind)
and (faulted_address + offset_ahead)
- run the tq_disk to actually start the IO.
- wait for the page that contains the faulted_address.
offset_behind and offset_ahead may be constant values or tuned at run-time
dynamically if some clever heuristic will be found.
Does the above make sense? (Or is it already implemented this way?)
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/