public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: rwhron@earthlink.net
Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org,
	lse-tech@lists.sourceforge.net
Subject: Re: big ext3 sequential write improvement in 2.5.51-mm1 gone in 2.5.53-mm1
Date: Thu, 23 Jan 2003 23:11:17 -0800	[thread overview]
Message-ID: <20030123231117.29c8eb98.akpm@digeo.com> (raw)
In-Reply-To: <20030124044119.GA15252@rushmore>

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.

  reply	other threads:[~2003-01-24  7:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-24  4:41 big ext3 sequential write improvement in 2.5.51-mm1 gone in 2.5.53-mm1 rwhron
2003-01-24  7:11 ` Andrew Morton [this message]
2003-01-24 15:54   ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030123231117.29c8eb98.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=piggin@cyberone.com.au \
    --cc=rwhron@earthlink.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox