From: Benjamin LaHaise <bcrl@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Adam Kropelin <akropel1@rochester.rr.com>, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.18pre3-ac1
Date: Sun, 13 Jan 2002 21:13:21 -0500 [thread overview]
Message-ID: <20020113211321.C32700@redhat.com> (raw)
In-Reply-To: <028b01c19c90$87300760$02c8a8c0@kroptech.com> <E16PvI2-0008WI-00@the-village.bc.nu>
In-Reply-To: <E16PvI2-0008WI-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Mon, Jan 14, 2002 at 12:47:54AM +0000
On Mon, Jan 14, 2002 at 12:47:54AM +0000, Alan Cox wrote:
> That is very useful information actually. That does rather imply that some
> of the performance hit came from the block I/O elevator differences in the
> old ac tree (the ones Linus hated ;)). Now the question (and part of the
> reason Linus didnt like them) - is why ?
Iirc, Linus just didn't like the low/high watermarks for starting & stopping
io. Personally, I liked it and wanted to use that mechanism for deciding
when to submit additional blocks from the buffer cache for the device (it
provides a nice means of encouraging batching). The problem that started
this whole mess was a combination of the missing wake_up in the block layer
that I found, plus the horrendous io latency that we hit with a long io queue
and no priorities. The critical pages for swap in and program loading, as
well as background write outs need to have a priority boost so that
interactive feel is better. Of course, with quite a few improvements in
when we wait on ios going into the vm between 2.4.7 and 2.4.17, we don't
wait as indiscriminately on io as we did back then. But write out latency
can still harm us.
In effect, it is a latency vs thruput tradeoff.
-ben
next prev parent reply other threads:[~2002-01-14 2:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-13 21:44 Linux 2.4.18pre3-ac1 Alan Cox
2002-01-13 19:23 ` Thiago Rondon
2002-01-13 22:52 ` Ville Herva
2002-01-13 22:57 ` Alan Cox
2002-01-14 0:15 ` Adam Kropelin
2002-01-14 0:47 ` Alan Cox
2002-01-14 2:13 ` Benjamin LaHaise [this message]
2002-01-14 2:54 ` Rik van Riel
2002-01-14 5:47 ` Eric W. Biederman
2002-01-14 6:17 ` Rik van Riel
2002-01-14 7:25 ` Eric W. Biederman
2002-01-14 9:28 ` David S. Miller
2002-01-14 12:05 ` Rik van Riel
2002-01-21 3:46 ` Daniel Phillips
2002-01-21 5:30 ` Richard Gooch
2002-01-21 5:34 ` Rik van Riel
2002-01-21 7:01 ` Eric W. Biederman
2002-01-21 12:02 ` Rik van Riel
2002-01-21 14:02 ` Daniel Phillips
2002-01-21 13:22 ` Daniel Phillips
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=20020113211321.C32700@redhat.com \
--to=bcrl@redhat.com \
--cc=akropel1@rochester.rr.com \
--cc=alan@lxorguk.ukuu.org.uk \
--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