linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@arcor.de>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Andrew Morton <akpm@digeo.com>,
	Lorenzo Allegrucci <l.allegrucci@tiscalinet.it>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: qsbench, interesting results
Date: Tue, 1 Oct 2002 19:03:40 +0200	[thread overview]
Message-ID: <E17wQQv-0005vB-00@starship> (raw)
In-Reply-To: <Pine.LNX.4.44L.0210011348060.653-100000@duckman.distro.conectiva>

On Tuesday 01 October 2002 18:52, Rik van Riel wrote:
> On Tue, 1 Oct 2002, Daniel Phillips wrote:
> > On Monday 30 September 2002 07:57, Andrew Morton wrote:
> > > I'll take a look at some preferential throttling later on.  But
> > > I must say that I'm not hugely worried about performance regression
> > > under wild swapstorms.  The correct fix is to go buy some more
> > > RAM, and the kernel should not be trying to cater for underprovisioned
> > > machines if that affects the usual case.
> >
> > The operative phrase here is "if that affects the usual case".
> > Actually, the quicksort bench is not that bad a model of a usual case,
> > i.e., a working set 50% bigger than RAM.
> 
> Having the working set of one process larger than RAM is
> a highly unusual case ...

No it's not, it's very similar to having several processes active whose
working sets add up to more than RAM.

> > The page replacement algorithm ought to do something sane with it,
> 
> ... page replacement ought to give this process less RAM
> because it isn't going to get enough to run anyway. No need
> to have a process like qsbench make other processes run
> slow, too.

It should run the process as efficiently as possible, given that there
isn't any competition.

> > and swap performance ought to be decent in general, since desktop users
> > typically have less than 1/2 GB.  With media apps, bloated desktops and
> > all, it doesn't go as far as it used to.
> 
> The difference there is that desktops don't have a working
> set larger than RAM. They've got a few (dozen?) of processes,
> each of which has a working set that easily fits in ram and
> a bunch of pages, or whole processes, which aren't currently
> in use.

Try loading a high res photo in gimp and running any kind of interesting
script-fu on it.  If it doesn't thrash, boot with half the memory and
repeat.

> In this situation the VM _can_ keep the whole working set in
> RAM, simply by evicting the stuff that's not in the working
> set.

We're not talking about that case.  Oh, by the way, since when did
it become ok to ignore corner cases?  I thought corner cases were what
users have been flaming us about for the last 2 or 3 years.

> > My impression is that page replacement just hasn't gotten a lot of
> > attention recently, and there is nothing wrong with that.  It's tuning,
> > not a feature.
> 
> As you write above, it's a pretty damn important feature,
> though.  One thing I'm experimenting with now for 2.4 rmap
> is to ignore the referenced bit and page age if a page is
> only in use by processes which haven't run recently, this
> should help the desktop (and university) workloads by
> swapping out memory from tasks which don't need it anyway
> at the moment.
> 
> There may be other modifications needed, too...

No doubt, and for the first time, we've got a solid base to build on.

-- 
Daniel

  reply	other threads:[~2002-10-01 17:02 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 [this message]
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

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=E17wQQv-0005vB-00@starship \
    --to=phillips@arcor.de \
    --cc=akpm@digeo.com \
    --cc=l.allegrucci@tiscalinet.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    --subject='Re: qsbench, interesting results' \
    /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

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