mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Ornati <ornati@lycos.it>
To: Andrew Morton <akpm@osdl.org>
Cc: gandalf@wlug.westbo.se, linuxram@us.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: Strange IDE performance change in 2.6.1-rc1 (again)
Date: Sun, 4 Jan 2004 15:30:24 +0100	[thread overview]
Message-ID: <200401041530.24395.ornati@lycos.it> (raw)
In-Reply-To: <20040103144003.07cc10d9.akpm@osdl.org>

On Saturday 03 January 2004 23:40, Andrew Morton wrote:
> Paolo Ornati <ornati@lycos.it> wrote:
> > I know these are only performance in sequential data reads... and real
> > life is another thing... but I think the author of the patch should be
> > informed (Ram Pai).
>
> There does seem to be something whacky going on with readahead against
> blockdevices.  Perhaps it is related to the soft blocksize.  I've never
> been able to reproduce any of this.
>
> Be aware that buffered reads for blockdevs are treated fairly differently
> from buffered reads for regular files: they only use lowmem and we always
> attach buffer_heads and perform I/O against them.
>
> No effort was made to optimise buffered blockdev reads because it is not
> very important and my main interest was in data coherency and filesystem
> metadata consistency.
>
> If you observe the same things reading from regular files then that is
> more important.

I have done some tests with this stupid script and it seems that you are 
right:
_____________________________________________________________________
#!/bin/sh

DEV=/dev/hda7
MOUNT_DIR=mnt
BIG_FILE=$MOUNT_DIR/big_file

mount $DEV $MOUNT_DIR
if [ ! -f $BIG_FILE ]; then
    echo "[DD] $BIG_FILE"
    dd if=/dev/zero of=$BIG_FILE bs=1M count=1024
    umount $MOUNT_DIR
    mount $DEV $MOUNT_DIR
fi

killall5
sleep 2
sync
sleep 2

time cat $BIG_FILE > /dev/null
umount $MOUNT_DIR
_____________________________________________________________________


Results for plain 2.6.1-rc1 (A) and 2.6.1-rc1 without Ram Pai's patch (B):

o readahead = 256 (default setting)

(A)
real	0m43.596s
user	0m0.153s
sys	0m5.602s

real	0m42.971s
user	0m0.136s
sys	0m5.571s

real	0m42.888s
user	0m0.137s
sys	0m5.648s

(B)
real    0m43.520s
user    0m0.130s
sys     0m5.615s

real	0m42.930s
user	0m0.154s
sys	0m5.745s

real	0m42.937s
user	0m0.120s
sys	0m5.751s


o readahead = 128

(A)
real	0m35.932s
user	0m0.133s
sys	0m5.926s

real	0m35.925s
user	0m0.146s
sys	0m5.930s

real	0m35.892s
user	0m0.145s
sys	0m5.946s

(B)
real	0m35.957s
user	0m0.136s
sys	0m6.041s

real	0m35.958s
user	0m0.136s
sys	0m5.957s

real	0m35.924s
user	0m0.146s
sys	0m6.069s


o readahead = 64
(A)
real	0m35.284s
user	0m0.137s
sys	0m6.182s

real	0m35.267s
user	0m0.134s
sys	0m6.110s

real	0m35.260s
user	0m0.149s
sys	0m6.003s


(B)
real	0m35.210s
user	0m0.149s
sys	0m6.009s

real	0m35.341s
user	0m0.151s
sys	0m6.119s

real	0m35.151s
user	0m0.144s
sys	0m6.195s


I don't notice any big difference between kernel A and kernel B....

>From these tests the best readahead value for my HD seems to be 64... and 
the default setting (256) just wrong.

With 2.4.23 kernel and readahead = 8 I get results like these:

real	0m40.085s
user	0m0.130s
sys	0m4.560s

real	0m40.058s
user	0m0.090s
sys	0m4.630s

Bye.

-- 
	Paolo Ornati
	Linux v2.4.23



  reply	other threads:[~2004-01-04 14:31 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-02 16:02 Paolo Ornati
2004-01-02 18:08 ` Ed Sweetman
2004-01-02 21:04   ` Paolo Ornati
2004-01-02 21:27     ` Valdis.Kletnieks
2004-01-03 10:20       ` Paolo Ornati
2004-01-02 21:32     ` Mike Fedyk
2004-01-02 22:34       ` Martin Josefsson
2004-01-03 11:13         ` Paolo Ornati
2004-01-03 22:40           ` Andrew Morton
2004-01-04 14:30             ` Paolo Ornati [this message]
2004-01-05 23:19               ` Ram Pai
2004-01-07 14:59                 ` Paolo Ornati
2004-01-07 19:23                   ` Ram Pai
2004-01-07 20:12                     ` Paolo Ornati
2004-01-07 23:57                       ` Andrew Morton
2004-01-08  7:31                         ` Ram Pai
2004-01-09  1:05                         ` Ram Pai
2004-01-09  1:17                           ` Andrew Morton
2004-01-09 19:15                             ` Ram Pai
2004-01-09 19:44                               ` Andrew Morton
2004-01-10 14:48                               ` Paolo Ornati
2004-01-10 16:00                                 ` Ed Sweetman
2004-01-10 16:19                                   ` Ed Sweetman
2004-01-10 17:29                                     ` Paolo Ornati
2004-01-10 17:29                                   ` Paolo Ornati
2004-03-29 15:45               ` Ram Pai
2004-01-04 17:15             ` Buffer and Page cache coherent? was: " Mike Fedyk
2004-01-04 22:10               ` Andrew Morton
2004-01-04 23:22                 ` Mike Fedyk
2004-01-04 23:32                   ` Andrew Morton
2004-01-04 23:45                     ` Mike Fedyk
2004-01-05  0:23                       ` Andrew Morton
2004-01-03 10:20       ` Paolo Ornati
2004-01-03  3:33     ` Tobias Diedrich
2004-01-03  4:15       ` Valdis.Kletnieks
2004-01-03 13:39         ` Tobias Diedrich
2004-01-03 20:56           ` Tobias Diedrich
2004-01-04  3:02         ` jw schultz

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=200401041530.24395.ornati@lycos.it \
    --to=ornati@lycos.it \
    --cc=akpm@osdl.org \
    --cc=gandalf@wlug.westbo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.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

Powered by JetHome