lkml.org 
[lkml]   [2003]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: big ext3 sequential write improvement in 2.5.51-mm1 gone in 2.5.53-mm1
rwhron@earthlink.net wrote:
>
> qsbench creates heavy swap load and simultaneous ed build. (small gnu package
> "tar xzf/configure/make/make check").

qsbench isn't really a thing which should be optimised for. It's just a mad
swapstorm, and as far as I can tell, its memory access patterns do not follow
normal locality-of-reference patterns.

The one thing we do learn from it is that to handle mad swapstorms, the 2.5
kernel needs load control. When you run multiple qsbench instances, they all
make equal progress and there is a tremendous amount of swapping.

In 2.4, individual instances of qsbench are able to hammer all the others
into the deck so they race ahead and exit, leaving more memory for the rest.
So 2.4 completes multithreaded qsbench in much less time than 2.5.

2.5 will complete single-instance qsbench in maybe 5% less time than 2.4,
which indicates that there's nothing fundamentally wrong or different, apart
from the fairness artifact.

(Well, 2.5 _used_ to run it faster. The anticipatory scheduling patch makes
2.5's qsbench a little slower than 2.4. `qsbench -m 350' on `mem=256m').

> Good numbers for this benchmark are open to interpretation, but more
> ed builds in less time is better. The "secs" column is how long it took
> for qsbench to do it's thing.

It is important to specify how much memory you have, and how you are
invoking qsbench.
-
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/

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