Messages in this thread | | | Date | Thu, 11 Dec 2003 11:16:10 +0100 | From | Roger Luethi <> | Subject | Re: 2.6.0-test9 - poor swap performance on low end machines |
| |
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 - 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/
| |