LKML Archive on
help / color / mirror / Atom feed
From: jos poortvliet <>
Cc: Con Kolivas <>, Andrew Morton <>,
Subject: Re: [ck] Re: Swap prefetch merge plans
Date: Fri, 09 Feb 2007 14:13:03 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]

> > > 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. 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 

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 

> 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...

> 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...

> > 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?

Sorry if I sound sarcastic. I'm no hacker myself, and sometimes these 
discussions don't make sense to me. A bit like the Staircase thingy ->

"hi, I've got this piece of code which does the same as that piece, but 
"Why didn't you improve the old code?"
"This is a better design -> half the code but doing a better job"
"Well, it's not tested as much, so it won't go in. Go away!"

There where those comments from Torvalds some time ago in an interview, about 
the kernel community becoming harder to get involved with. As an outsider, it 
sure seems so. I read frustrations everywhere. What about the kevent guy, his 

I stumbled upon it when reading LWN. Seems pretty sad... I don't get the 
technical stuff, but the frustration almost blows up your monitor. Is there 
something fundamentally wrong with the kernel-hackers-culture, or are these 




Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. 
Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat 
ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. 
Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

       reply	other threads:[~2007-02-09 13:11 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 [this message]
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
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).