From: Andrew Morton <akpm@zip.com.au>
To: "Dieter Nützel" <Dieter.Nuetzel@hamburg.de>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: Unresponiveness of 2.4.16
Date: Tue, 27 Nov 2001 18:13:41 -0800 [thread overview]
Message-ID: <3C044855.3CF2DCA3@zip.com.au> (raw)
In-Reply-To: <20011128013129Z281843-17408+21534@vger.kernel.org>
Dieter Nützel wrote:
>
> Andrew Morton wrote:
> > Jens Axboe wrote:
> > >
> > > I agree that the current i/o scheduler has really bad interactive
> > > performance -- at first sight your changes looks mostly like add-on
> > > hacks though.
> >
> > Good hacks, or bad ones?
>
> As I can "see" not so good.
> I've tried "dbench 32" and playing an MP3 with Noatun (KDE-2.2.2) and "saw"
> my reported hiccup since 2.4.7-ac4, as always.
Ah. dbench. The change to balance_dirty_state() absolutely
cripples dbench throughput. And that really doesn't matter,
unless you want to run dbench for a living.
You can get the dbench throughput back by increasing the
async and sync dirty buffer writeback thresholds:
echo 70 64 64 256 30000 3000 80 0 0 > /proc/sys/vm/bdflush
> Noatun stops after 9-10 seconds of the "dbench 32" run and then every few
> seconds, again and again. The hiccup take place more often but for shorter
> times then without your patch.
Probably Noatun needs larger buffers if it is to survive concurrent
dbench. You may see improvement with
elvtune -b N /dev/hdaX
where 8 >= N >= 1.
> System was:
>
> 2.4.16 +
> preempt +
> lock-break-rml-2.4.16-1.patch +
> all ReiserFS patches for 2.4.16
>
> 1 GHz Athlon II
> MSI MS-6167 Rev 1.0B (AMD Irongate C4, without bypass)
> 640 MB PC100-2-2-2 SDRAM
> U160 IBM 18 GB disk
> AHA-2940 UW
>
> > It keeps things localised. It works. It's tunable. It's the best
> > IO scheduler presently available.
>
> Throughput was a little lower ;-)
dbench? Throughput seems to scale with the fourth power of the
amount of RAM you chuck at it :)
> Don't forget to tune max-readahead.
Yes. Readahead is fairly critical and there may be additional fixes
needed in this area.
Someone recently added the /proc/sys/vm/max_readahead (?) tunable.
Beware of this. It only works for device drivers which do not
populate their own readhead table. For IDE, it *looks* like
it works, but it doesn't. For IDE, the only way to alter VM
readahead is via
echo file_readahead:N > /proc/ide/ide0/hda/settings
where N is in kilobytes in 2.4.16 kernels. In earlier kernels
it's kilopages (!).
-
next prev parent reply other threads:[~2001-11-28 2:15 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-28 1:31 Unresponiveness of 2.4.16 Dieter Nützel
2001-11-28 2:13 ` Andrew Morton [this message]
2001-11-28 2:34 ` Mike Fedyk
2001-11-28 2:48 ` Andrew Morton
2001-11-28 20:21 ` Roger Larsson
2001-11-28 3:53 ` Dieter Nützel
[not found] ` <200111280353.fAS3rEB05638@zero.tech9.net>
2001-11-28 4:14 ` Robert Love
-- strict thread matches above, loose matches on Subject: below --
2001-11-28 19:42 Torrey Hoffman
2001-11-28 20:51 ` Dieter Nützel
2001-11-28 18:56 Torrey Hoffman
2001-11-28 19:31 ` Andrew Morton
2001-11-28 0:33 Torrey Hoffman
2001-11-28 0:48 ` Andrew Morton
2001-11-28 18:09 ` Marcelo Tosatti
2001-11-28 19:38 ` Andrew Morton
2001-11-27 9:56 willy tarreau
2001-11-27 10:57 ` Heinz Diehl
2001-11-26 22:02 Nathan G. Grennan
2001-11-26 22:17 ` Alan Cox
2001-11-26 23:34 ` Nicolas Pitre
2001-11-27 0:05 ` Steve Lion
2001-11-27 9:12 ` Ahmed Masud
2001-11-27 17:12 ` Andrew Morton
2001-11-27 20:31 ` Mike Fedyk
2001-11-27 20:57 ` Andrew Morton
2001-11-27 21:19 ` Martin Eriksson
2001-11-27 21:24 ` Mike Fedyk
2001-11-28 18:24 ` Marcelo Tosatti
2001-11-28 18:57 ` Marcelo Tosatti
2001-11-28 20:31 ` Andrew Morton
2001-11-28 20:56 ` Andreas Dilger
2001-11-28 21:12 ` Andrew Morton
2001-11-28 20:04 ` Marcelo Tosatti
2001-11-28 21:26 ` Andrew Morton
2001-11-26 23:59 ` Rik van Riel
2001-11-27 0:36 ` Andrew Morton
2001-11-27 0:46 ` Rik van Riel
2001-11-27 4:38 ` Mike Fedyk
2001-11-27 4:45 ` Andrew Morton
2001-11-27 1:45 ` Andrea Arcangeli
2001-11-26 22:21 ` Andrew Morton
2001-11-27 7:42 ` Jens Axboe
2001-11-27 7:58 ` Mike Fedyk
2001-11-27 8:01 ` Jens Axboe
2001-11-27 8:31 ` Andrew Morton
2001-11-27 8:38 ` Jens Axboe
2001-11-26 22:44 ` Lincoln Dale
2001-11-27 4:34 ` GOTO Masanori
2001-11-27 0:44 ` Lost Logic
2001-11-27 0:57 ` Lost Logic
2001-11-27 3:49 ` Sean Elble
2001-11-27 3:56 ` Doug Ledford
2001-11-27 4:00 ` Sean Elble
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=3C044855.3CF2DCA3@zip.com.au \
--to=akpm@zip.com.au \
--cc=Dieter.Nuetzel@hamburg.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.