[lkml]   [2003]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.0-test9 - poor swap performance on low end machines
On Wed, Dec 10, 2003 at 11:05:25PM +0100, Roger Luethi wrote:
> On Wed, 10 Dec 2003 22:52:35 +0100, Andrea Arcangeli wrote:
> > On Mon, Dec 08, 2003 at 12:48:17PM -0800, William Lee Irwin III wrote:
> > > qsbench I'd pretty much ignore except as a control case, since there's
> > > nothing to do with a single process but let it thrash.
> >
> > this is not the point. If a single process like qsbench trashes twice as
> > fast in 2.4, it means 2.6 has some great problem in the core vm, the
> > whole point of swap is to trash but to give the task more physical
> > virtual memory. I doubt you can solve it with anything returned by
> > si_swapinfo.
> Uhm.. guys? I forgot to mention that earlier: qsbench as I used it was not
> about one single process. There were four worker processes (-p 4), and my
> load control stuff did make it run faster, so the point is moot.

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.

> 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
information more efficiently at the expenses of all the fast paths
that now have to do the rmap bookkeeping.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:59    [W:0.070 / U:9.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site