[lkml]   [1998]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] swapin readahead and fixes

    On Fri, 4 Dec 1998 15:02:56 +0100 (CET), Rik van Riel
    <> 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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.021 / U:6.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site