mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mikhail Ramendik <mr@ramendik.ru>
To: linux-kernel@vger.kernel.org
Subject: 2.6.5-rc3-mm4 eats more CPU on disk i/o than 2.4 line (VIA chipset)
Date: Tue, 06 Apr 2004 02:00:10 +0400	[thread overview]
Message-ID: <1081202409.1036.3.camel@localhost.localdomain> (raw)

Hello,

After discussions in the "100% cpu use" thread, I have done some careful
testing, and updated the tools to see the difference between "system"
and "iowait" time. And I still see that the 2.6 line eats more CPU time
on disk I/O than the 2.4 line, albeit it also has better system
performance.

I have a system with a Duron 650 CPU, KT133 chipset, 256 MB RAM, Seagate
Barracuda 7200.7 HDD.

The testing procedure is as follows. I run an endless loop of copying a
file to the same directory (on ext3fs). In another window I run ubench
(http://www.phystech.com/download/ubench.html), a CPU benchmark (it also
can benchmark memory but I look at the CPU results; the memory footprint
is quite small at about 1.5MB, so I don't think swapping is a part of
the picture).

In a third window I look at top, running it as root to make sure I see
everything.

I used kernel 2.6.5-rc3-mm4. I tried running it with usual options and
with the deadline elevator. I also did the sate test under stock distro
(RH9-based) kernel 2.4.20, for comparison.

In 2.6.5-rc3-mm4, the 100% cpu use on copying  breaks down into "system"
and "iowait"; these two values vary over time but stay within some
bounds. When I run the benchmark, iowait falls to zero, apparently it
gets given over to the benchmark; the "system" is either unchanged or
climbs up about 5%.

The "system" CPU use varied over time. Without the deadline elevator, it
was jumping up and down within the range of 25% to 40%, occasionally
more; with the deadline elevator, significantly lower, at 20% to 25%.

In 2.4.20 iowait was shown as zero. The "system" CPU use was at 10% to
20%, and stayed within these borders when the benchmark was run.

And of course, the more "system" CPU usage there is, the less are the
results given by the benchmark. Therefore the results were highest on
2.4.20, and lowest on 2.6.4-rc3-mm4 without the deadline elevator. (The
proportion is quite simple so I don't include benchmark values here).

So, the 2.6.5-rc3-mm4 kernel took more CPU away for disk operation than
the 2.4.20 kernel. But on the other hand, disk performance is increased
(especially without the deadline evelator - and there the CPU usage is
highest too).

I am ready to do more benchmarking if and when necessary, to whatever
specs necessary. Just tell me what to try (no trojans ;)

I'm not sure if this is a genuine problem, or a valid trade-off of CPU
time for disk performance. The 2.6 line does seem more responsive when
disk operations are going on.

The final word here, of course, is with the developers. 

Yours, Mikhail Ramendik




                 reply	other threads:[~2004-04-05 22:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1081202409.1036.3.camel@localhost.localdomain \
    --to=mr@ramendik.ru \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®