lkml.org 
[lkml]   [1998]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] swapin readahead and fixes
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. 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.

--Stephen

-
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:45    [W:0.147 / U:0.032 seconds]
©2003-2011 Jasper Spaans. Advertise on this site