Re: 2.6.0-test9 - poor swap performance on low end machines

[Roger Luethi <rl@hellgate.ch>]

On Wed, 10 Dec 2003 23:44:46 +0100, Andrea Arcangeli wrote:
> more processes can be optimized even better by adding unfariness.
> Either ways a significant slowdown of qsbench probably means worse core
> VM, at least if compared with 2.4 that isn't adding huge unfariness just
> to optimize qsbench.

Can you be a bit more specific about the type of unfairness? The only
instance I clearly noticed is that one process can grow its RSS at the
expense of others if they already have a high PFF. That happens more
often in 2.4 and helps a lot with some benchmarks.

I did notice, though, that after an initial slowdown, qsbench improved
during 2.5, while the compile benchmarks got even worse.

> > Also, the 2.6 core VM doesn't seem all that bad since it was introduced in
> > 2.5.27 but most of the problems I measured were introduced after 2.5.40.
> > Check out the graph I posted.
> 
> you're confusing rmap with core vm. rmap in no way can be defined as the
> core vm, rmap is just a method used by the core vm to find some

Incidentally, all these places where rmap is used by the core VM were
introduced in 2.5.27 as well. In particular vmscan.c was completely
overhauled. But apparently you suspect subsequent changes to the core
to be a problem. I am curious what they are if that can help fixing
the slowdowns I'm seeing.

Roger