archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <>
To: Andrew Morton <>
Cc: Lorenzo Allegrucci <>,
	Linux Kernel <>
Subject: Re: qsbench, interesting results
Date: Tue, 1 Oct 2002 20:35:28 +0200	[thread overview]
Message-ID: <E17wRrk-0005vp-00@starship> (raw)
In-Reply-To: <>

On Tuesday 01 October 2002 20:04, Andrew Morton wrote:
> I'm fairly happy with 2.5 page replacement.  It's simple, clean
> and very, very quick to build up a large pool of available memory
> for what ever's going on at the time.
> Problem is, it's cruel.  People don't notice that we shaved 15 seconds
> off that three minute session of file bashing which they just did.
> But they do notice that when they later wiggle their mouse, it takes
> five seconds to pull the old stuff back in. 
> The way I'd like to address that is with a "I know that's cool but I
> don't like it" policy override knob.  But finding a sensible way of
> doing that is taking some head-scratching.  Anything which says
> "unmap pages much later" is doomed to failure I suspect.  It will
> just increase latency when we really _do_ need to unmap, and will
> cause weird OOM failures.
> So hm.  Still thinking.

That would be process RSS management you're talking about, which Rik
has bravely volunteered to tackle.  The object would be to respond to
-nice values as sanely as possible, so that a reasonable portion of
those pages touched by the mouse tend to stick around in memory under
all but the highest pressure loads.

Then there is the 'updatedb paged out my desktop in the middle of the
night', related but even harder because of the long timeframe.  To fix
this really well and not kill other, more critical loads requires some
kind of memory of what was paged out when so that when updatedb goes
away, something approximating the former working set pops back in.  A
little low hanging fruit can be gotten by just reading all of swap
back in when the load disappears, which will work fine when swap is
smaller than RAM and there isn't too much shared memory.


      parent reply	other threads:[~2002-10-01 18:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-29 14:15 Lorenzo Allegrucci
2002-09-29 16:26 ` bert hubert
2002-09-29 19:56   ` Lorenzo Allegrucci
2002-09-29 20:00     ` bert hubert
2002-09-29 21:05       ` Lorenzo Allegrucci
2002-09-30  5:57 ` Andrew Morton
2002-10-01 14:05   ` Daniel Phillips
2002-10-01 16:52     ` Rik van Riel
2002-10-01 17:03       ` Daniel Phillips
2002-10-01 17:13         ` Rik van Riel
2002-10-01 17:20           ` Daniel Phillips
2002-10-01 17:29             ` Rik van Riel
2002-10-01 17:38               ` Daniel Phillips
2002-10-01 18:18         ` Lorenzo Allegrucci
2002-10-01 17:15       ` Larry McVoy
2002-10-01 18:04     ` Andrew Morton
2002-10-01 18:20       ` Rik van Riel
2002-10-01 18:35       ` Daniel Phillips [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:

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

  git send-email \
    --in-reply-to=E17wRrk-0005vp-00@starship \ \ \ \ \
    --subject='Re: qsbench, interesting results' \

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