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

On Saturday 10 February 2007 00:13, jos poortvliet wrote:
> > > > Hold.
> > >
> > > Why hold?
> > >
> > > It's been shown this patchset really helps desktop users.
> >
> > Has it?  I don't think I've ever observed any benefits from it and I
> > don't think anyone has ever got down and worked out what its drawbacks
> > might be, and seen if they can be demonstrated in practice.
> Well, I'd say it's disadvantage is that you might use the buffered diskdata
> in memory (which will be replaced with application data from swap) when you
> come back using the computer. But it's far more likely you'll use the app
> data, that's why swap prefetch helps

swap prefetch stores the data at the tail end of the lru list which means that 
even if you do want to use that ram for something else, the prefetched pages 
will be immediately dropped. Since the pages are still on backing store 
(swapspace) they will be droppped without any further I/O. 

> . Anyway, I'm sure you got some 
> response from users who did like it. Now I know the desktop isn't the focus
> of the Linux Kernel Developers, and you probably have much to hefty
> hardware to notice any difference. Heck, after my upgrade to 3GB ram, I
> never noticed swap prefetch anymore...

Even on 2GB ram at home, where I regularly move iso images around, compress 
large files with big window compression apps (like rzip), manipulate gimp 
images, print large colour photos in high resolution and so on, I hit swap 
regularly and do notice it being helpful. This is what normal desktop users 

> But there ARE ppl using KDE or Gnome on a 256 MB ram system (or even less)
> and they would notice this. I know I do on my 192-mb-ram laptop with
> Kubuntu... It's lovely to do some compiling task, then while you work in vi
> swap prefetch ensures everything is smooth when you try to continue
> browsing with firefox...


> > I also have vague memories of some serious-sounding review comments about
> > the code from Nick.
> Nick's comment, replying to me some time ago:
> > > well, the reason i use it is my computer is much more reactive in the
> > > morning. linux uses to get very slow after a night of not-doing-much
> > > except some 'sleep 5h && blabla' and cron stuff. in the morning it
> > > takes a few HOURS to get up and running smoothly. with swap prefetch,
> > > it actually feels faster compared to a fresh boot. now you can force
> > > swap prefetch to start working, i use it now and then after some heavy
> > > taskts which pulled everything to swap.
> >
> > I have two issues with this argument (not that I'm trying to say it
> > couldn't make a difference in your case).
> >
> > Firstly, swap prefetch actually doesn't handle the midnight updatedb
> > pageout problem nicely. It doesn't do any prefetching when the
> > pagecache/vfs cache fills memory (which is what would have to happen for
> > updatedb to push stuff into swap).
> But doesn't it prefetch stuff after updatedb has run and the computer is
> idle? Updatedb here runs at night, and swap prefetch is supposed to get my
> app data back in memory during the time after updatedb pushed it out,
> right? Maybe Con can explain here...

It can't help the updatedb scenario. Updatedb leaves the ram full and swap 
prefetch wants to cost as little as possible so it will never move anything 
out of ram in preference for the pages it wants to swap back in. The use once 
logic in the vm might if you're lucky help the next time you use the memory, 
but anything you used prior to updatedb is trashed beyond oblivion and this 
has nothing to do with swap prefetch.

> > Secondly, with or without swap prefetch, I think we can do a better job
> > of handling these use-once patterns to begin with.
> well, i'd love to see you elaborate on this. I mean, if the kernel could be
> made smarter and swap prefetch wouldn't be needed, great...

They're not mutually exclusive. We will _always_ have a load that causes 
swapping. Whatever the resources available on a pc, an application will come 
along that outstrips it. The nature of normal desktops is they're always 
driven to this level.

> > > Why keep it in -mm for so long?
> >
> > I'm waiting to be shown that its benefits exceed its costs.  Sometimes
> > that's hard.
> Nobody has said anything about costs, indeed. Now afaik, swap prefetch is
> designed to have no/as little as possible costs, so that makes sense. Does
> it have to have some bugs, which have to be adressed, before it can enter?
> I'm sure this can be arranged, right, Con?

I'm stuck developing code I'm having trouble proving it helps. Normal users 
find it helps and an artificial testcase shows it helps, but that is not 
enough, since the normal users will be tainted in their opinion, and the 
artificial testcase will always be artificial. My mistake of developing novel 
code in areas that were unquantifiable has been my undoing.  If it's 
unquantifiable, but "obvious" then it has a chance...(like most of what goes 
into mainline). Precious few of the patches that I keep in -ck belong to that 
group though. 

P.S. Sorry about being harsh in the last email Jos, I understood your 


  parent reply	other threads:[~2007-02-09 13:57 UTC|newest]

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

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: [ck] 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).