public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Lincoln Dale <ltd@cisco.com>
Cc: Benjamin LaHaise <bcrl@redhat.com>,
	Andrea Arcangeli <andrea@suse.de>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	Steve Lord <lord@sgi.com>,
	linux-kernel@vger.kernel.org
Subject: Re: ext2 performance in 2.5.25 versus 2.4.19pre8aa2
Date: Sun, 14 Jul 2002 22:30:19 -0700	[thread overview]
Message-ID: <3D325DEB.A9920C12@zip.com.au> (raw)
In-Reply-To: 5.1.0.14.2.20020714202539.022c4270@mira-sjcm-3.cisco.com

Lincoln Dale wrote:
> 
> Andrew Morton wanted me to do some benchmarking of large files on ext2
> filesystems rather than the usual block-device testing
> i've had some time to do this, here are the results.
> 
> one-line summary is that some results are better, some are worse; CPU usage
> is better in 2.5.25, but thoughput is sometimes
> worse.

Well thanks for doing this.  All rather strange though.

- You should definitely be seeing reduced CPU on writes through the
  pagecache.  A whole pile of gunk has disappeared from there.
  Here's what I get with 4x4gig files on 4xIDE disks:

for i in hde5 hdg5 hdi5 hdk5
do
	/usr/src/ext3/tools/write-and-fsync -m 4000 -f /mnt/$i/foo &
done

2.4.19-rc1+block_highmem 0.06s user 106.75s system 53% cpu 3:20.94 total
2.5.25                   0.03s user 78.37s system 40% cpu 3:14.82 total
2.5.25+some stuff        0.05s user 77.91s system 41% cpu 3:07.70 total
2.5.25+O_DIRECT          0.00s user 6.84s system 3% cpu 2:53.21 total


That's a 25% drop in CPU load for writes in 2.5.  Actually more, because
Andre's current 2.5 IDE drivers are using teeny requests and are measurably
slow.

That's how it should be, and it is strange that you're not showing
decreased CPU and increased throughput on writes.

- For reads through the pagecache you're showing good reduction in CPU
  and some increase in bandwidth.

When reading the above 4 files in parallel on the IDE setup I show:

for i in hde5 hdg5 hdi5 hdk5
do
	time /usr/src/ext3/tools/time-read -b 8192 -h 8192 /mnt/$i/foo &
done                

2.5.25:                      0.43s user 42.74s system 31% cpu 2:17.87 total
2.4.19-rc1+block-highmem:    0.37s user 54.48s system 40% cpu 2:16.17 total
2.4.19-rc1:                  0.63s user 129.21s system 76% cpu 2:49.66 total

A 25% drop in CPU load on buffered reads in 2.5.


Funny thing about your results is the presence of sched_yield(),
especially in the copy-from-pagecache-only load.  That test should
peg the CPU at 100% and definitely shouldn't be spending time in
default_idle.  So who is calling sched_yield()?  I think it has to be
your test app?

Be aware that the sched_yield() behaviour in 2.5 has changed a lot
wrt 2.4.  It has made StarOffice 5.2 completely unusable on a non-idle
system, for a start.  (This is a SO problem and not a kernel problem,
but it's a lesson).

-

  reply	other threads:[~2002-07-15  5:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-08  3:19 direct-to-BIO for O_DIRECT Andrew Morton
2002-07-08  3:30 ` Lincoln Dale
2002-07-08  7:44 ` Ingo Oeser
2002-07-11  2:25 ` Lincoln Dale
2002-07-11  3:24   ` Andrew Morton
2002-07-11  3:25     ` Lincoln Dale
     [not found]       ` <3D2CFF48.9EFF9C59@zip.com.au>
2002-07-14 12:22         ` ext2 performance in 2.5.25 versus 2.4.19pre8aa2 Lincoln Dale
2002-07-15  5:30           ` Andrew Morton [this message]
2002-07-15  6:06             ` Lincoln Dale
2002-07-15  6:52               ` Andrew Morton
2002-07-15  9:49               ` Andrea Arcangeli
2002-07-15 10:16                 ` Lincoln Dale
2002-07-15 18:08                 ` Andrew Morton
2002-07-17 19:22             ` Daniel Phillips
2002-07-15 16:30           ` Benjamin LaHaise
2002-07-11 19:52   ` direct-to-BIO for O_DIRECT Jesse Barnes
2002-07-11 23:40     ` Lincoln Dale

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=3D325DEB.A9920C12@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=andrea@suse.de \
    --cc=bcrl@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lord@sgi.com \
    --cc=ltd@cisco.com \
    --cc=sct@redhat.com \
    --cc=torvalds@transmeta.com \
    /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