LKML Archive on
help / color / mirror / Atom feed
From: Con Kolivas <>
Cc: Andrew Morton <>,
Subject: Re: Swap prefetch merge plans
Date: Sat, 10 Feb 2007 09:49:50 +1100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Saturday 10 February 2007 07:50, Con Kolivas wrote:
> On Saturday 10 February 2007 07:30, Andrew Morton wrote:
> > On Fri, 09 Feb 2007 14:13:03 +0100
> >
> > jos poortvliet <> wrote:
> > > Nick's comment, replying to me some time ago:
> >
> > I think I was thinking of this:
> >
> >
> Fortunately that predates a lot of changes where I did address all those.
> These will seem out of context without looking at that original email so I
> apologise in advance.
> buffered_rmqueue and prefetching x86 specific (not into DMA) were dropped
> It is NUMA aware
> Global cacheline bouncing in page allocation and page reclaim paths I have
> no answer for as I have to tell swap prefetch that the vm is busy somehow
> and I do that by setting precisely one bit in a lockless manner.
> The trylocks were dropped.
> The other ideas were to :
> -extend the prefetching. That's extra features
> -knowing for sure when a system is really idle. I've tried hard to do that
> as cheaply as possible.
> -putting pages on the lru? well it puts them on the tail
> -papering over an issue? As I said, no matter how good the vm is, there
> will always be loads that swap.

Perhaps I haven't made this clear enough.

Nick has been kind enough to review pretty much all of swap prefetch at every 
turn. He is understandably suspicious about any code that I generate since 
I'm a doctor and not a computer programmer. I have addressed every concern he 
has made along the way and even joked at the end that he "threatened to 
review it over and over and over" which he did not take in jest. 

Swap prefetch has actually had far more review than a lot of code so I'm 
surprised that this is a remaning concern.  It has been reviewed, and I have 
addressed the concerns. It is possible to hold back code forever at the 
suggestion that more review is always required, and basically that's what I 
feel this has become.

If there is one valid concern with swap prefetch, there is a numa=64 scenario 
that Rohit Seth brought to my attention and I gave him a patch to test 2 
months ago. I've pinged him since, but I understand he's busy so has not had 
a chance to test the patch.


  reply	other threads:[~2007-02-09 22:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
2007-02-09 13:13     ` [ck] " jos poortvliet
2007-02-09 13:22       ` Con Kolivas
2007-02-09 14:00         ` jos poortvliet
2007-02-09 13:56       ` Con Kolivas
2007-02-09 20:30       ` Andrew Morton
2007-02-09 20:50         ` Con Kolivas
2007-02-09 22:49           ` Con Kolivas [this message]
2007-02-09 23:35         ` Chuck Ebbert
2007-02-09 23:54           ` Randy Dunlap
2007-02-10 16:12             ` jos poortvliet
2007-02-09 18:09 Andrew Burgess
2007-02-09 20:12 ` Con Kolivas

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:

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

  git send-email \ \ \ \ \ \
    --subject='Re: Swap prefetch merge plans' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).