linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	Linux MM <linux-mm@kvack.org>,
	Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject: Re: [PATCH] swapin readahead and fixes
Date: Fri, 4 Dec 1998 14:34:01 GMT	[thread overview]
Message-ID: <199812041434.OAA04457@dax.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.3.96.981204150030.15134N-100000@mirkwood.dummy.home>

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
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

  reply	other threads:[~1998-12-04 14:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-03 17:56 Rik van Riel
1998-12-04 11:34 ` Stephen C. Tweedie
1998-12-04 14:02   ` Rik van Riel
1998-12-04 14:34     ` Stephen C. Tweedie [this message]
1998-12-05  9:46       ` Gerard Roudier
1998-12-07 16:50         ` Stephen C. Tweedie
1998-12-08  1:34           ` Billy Harvey
1998-12-08  2:31             ` Rik van Riel
1998-12-08  2:51               ` Billy Harvey
1998-12-08  3:00                 ` Rik van Riel
1998-12-08 12:35               ` Stephen C. Tweedie
1998-12-08 13:51                 ` Rik van Riel
1998-12-09  2:41               ` Drago Goricanec
1998-12-09 11:58                 ` Stephen C. Tweedie
1998-12-08 12:21             ` Stephen C. Tweedie
1998-12-05 10:47       ` Gerard Roudier
1998-12-04 19:25 ` Chris Evans
1998-12-04 20:47   ` Rik van Riel
1998-12-05 18:59     ` Alan Cox
1998-12-05 19:02       ` Rik van Riel
1998-12-06  5:20       ` Rik van Riel
1998-12-06  5:23       ` Steve VanDevender
1998-12-07 11:52   ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199812041434.OAA04457@dax.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox