public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wolly <wwolly@gmx.net>
To: linux-kernel@vger.kernel.org
Subject: Huge disk performance degradation in 2.4.9
Date: Fri, 21 Sep 2001 19:23:16 +0200	[thread overview]
Message-ID: <200109211723.TAA00638@enigma.deepspace.net> (raw)

Sorry if this is already known or fixed. 
I did not find something related in the last 2.4.10-pre changelog. 

I recently upgraded from 2.4.6 to 2.4.9 and since then noticed that my 
hd (old noisy thing in an old P100 box) repeatedly 
sounds strange (read on, please!) when dealing with lots of small files. 
(No physical problem; it's a kernel flushing issue.)

This turned out to be the sign of a quite huge performance loss anywhere 
between 2.4.7 and 2.4.9 (sorry, using a 56k Modem, I cannot test them 
all and it's a shame that I already deleted 2.4.6 sources). 

I verified this on a PII-350 (440BX, 196Mb) using 600 files (instead of 300). 
I only tested things on reiserfs (v3.6. using 3.5 partitions) becuase I 
don't have ext2 around any longer. 

For testing purposes, I used: 
sync ; cat /proc/version ; sleep 1 ; /usr/bin/time sh -c 'declare -i cnt=0 ; 
while test $cnt -lt 300 ; do echo -en "\b\b\b\b\b\b\b$cnt " ; 
dd if=/dev/zero of=file-$cnt bs=1 count=16 >/dev/null 2>&1 ; 
cnt=$cnt+1 ; done ; echo' ; rm file-*

This creates lots of 16-byte files using 16 write() calls [second test 
with 160kb files using 16 write() calls] and prints out the time 
(On P-100; 72Mb, 1Gb hd; besides kernel: equal setup for 
all tests; machine idle; all tests ran several times; all kernels compiled 
with gcc version 2.95.2 19991024 (release)): 

       |   (dd bs=1 count=16)    | (dd bs=10240 count=16)
kernel | user system elapsed CPU | user system elapsed CPU
2.4.9  | 3.12   5.10   32.46 25% | 3.84  14.31   73.09 24%
2.4.6  | 3.28   4.17    8.17 91% | 3.96  14.76   25.76 72%
2.2.19 | 2.82   3.75    7.12 92% | 4.42  12.90   19.26 89%
(user, system, elapsed time in seconds)

Look at the elapsed times! 2.4.9 takes >=3 times as long as 2.4.6 
(and 2.2.19 performs even better). 
This is a huge performance issue and I actually notice it using when 
squid or doing a CVS checkout with lots of small files. 

When listening to the hd you note a difference. While 2.4.6 does 
a clustered write call from time to time, 2.4.9 starts to burst out in 
accessing the hd (always moving the hd's head) and does not 
finish until the test is over (same with my PII-350 and IBM 12Gb) 

Anyone reproducing this? Reiserfs issue or cache/buffer/flush issue? 

Regards, 
Wolly

             reply	other threads:[~2001-09-21 17:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-21 17:23 Wolly [this message]
2001-09-21 23:29 ` Huge disk performance degradation in 2.4.9 Steve Kieu
2001-09-23 23:19 ` Huge disk performance degradation STILL IN 2.4.10 Wolly
2001-09-23 23:55   ` Chris Mason
2001-09-24 15:05     ` Wolly
2001-09-24 15:19       ` Andre Pang
2001-09-25 10:00         ` Wolly
2001-09-30 21:50           ` Tom Vier

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=200109211723.TAA00638@enigma.deepspace.net \
    --to=wwolly@gmx.net \
    --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