Re: qsbench, interesting results

From: Rik van Riel (riel@conectiva.com.br)
Date: Tue Oct 01 2002 - 11:52:25 EST


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

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

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

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.

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

regards,

Rik

-- 
A: No.
Q: Should I include quotations after my reply?

http://www.surriel.com/ http://distro.conectiva.com/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:27 EST