From: Andrew Morton <akpm@osdl.org>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org, ck@vds.kolivas.org
Subject: Re: [PATCH] vm - swap_prefetch v12
Date: Thu, 29 Sep 2005 16:52:45 -0700 [thread overview]
Message-ID: <20050929165245.77bf3411.akpm@osdl.org> (raw)
In-Reply-To: <200509300942.28843.kernel@kolivas.org>
Con Kolivas <kernel@kolivas.org> wrote:
>
> On Fri, 30 Sep 2005 09:24 am, Andrew Morton wrote:
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > On Fri, 30 Sep 2005 07:54 am, Andrew Morton wrote:
> > > > Con Kolivas <kernel@kolivas.org> wrote:
> > > > > Once pages have been added to the swapped list, a timer is started,
> > > > > testing for conditions suitable to prefetch swap pages every 5
> > > > > seconds. Suitable conditions are defined as lack of swapping out or
> > > > > in any pages, and no watermark tests failing. Significant amounts of
> > > > > dirtied ram also prevent prefetching. It then checks that we have
> > > > > spare ram looking for at least 3* pages_high free per zone and if it
> > > > > succeeds that will prefetch pages from swap.
> > > >
> > > > Did you consider poking around in gendisk.disk_stats to determine
> > > > whether the swap disk(s) are idleish?
> > >
> > > I didn't know where to look for that info. Thanks! I'm open to *any*
> > > suggestions and I'll look into it as I can't take this code much further
> > > without outside help.
> >
> > Might also be able to utilise CFQ's I/O priorities. That should be more
> > efective than a heuristic based on disk_stats, however you'd probably need
> > to work out whether the swapdev actually supports IO priorities and I'm not
> > sure how one would query that (cleanly).
>
> Good idea. It should be easy to simply add the ioprio value to the kprefetchd
> thread and it either supports it or it doesn't depending on what iosched is
> being used.
Right. But if the queue doesn't support io priorities then one might want
to fall back to monitoring recent queue activity.
> Further to your original suggestion, prefetching is already delayed when any
> non-prefetch related swap in or out is occurring already so checking
> diskstats is probably not going to add to that for swap activity. However I
> assume it (diskstats) could also be used for all disk i/o as well?
Precisely. Few people would set an entire disk aside for swap.
> Currently
> a lot of dirty data can tell me that lots of writing is happening but I have
> no way of checking that lots of reads are occurring.
diskstats will tell that. Also one could peek at the current disk queue
levels (request_list.count[]).
prev parent reply other threads:[~2005-09-29 23:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-29 15:15 Con Kolivas
2005-09-29 21:54 ` Andrew Morton
2005-09-29 23:12 ` Con Kolivas
2005-09-29 23:24 ` Andrew Morton
2005-09-29 23:42 ` Con Kolivas
2005-09-29 23:52 ` Andrew Morton [this message]
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=20050929165245.77bf3411.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ck@vds.kolivas.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®