From: Helge Hafting <helgehaf@aitel.hist.no>
To: Valdis.Kletnieks@vt.edu
Cc: Michael Frank <mhf@linuxmail.org>,
Nick Piggin <piggin@cyberone.com.au>,
Giuliano Pochini <pochini@shiny.it>,
Andrea Arcangeli <andrea@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: ext2/3 performance regression in 2.6 vs 2.4 for small interl
Date: Thu, 12 Feb 2004 21:55:03 +0100 [thread overview]
Message-ID: <20040212205503.GA13934@hh.idb.hist.no> (raw)
In-Reply-To: <200402121718.i1CHITFf018390@turing-police.cc.vt.edu>
On Thu, Feb 12, 2004 at 12:18:29PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 13 Feb 2004 01:05:20 +0800, Michael Frank said:
>
> > What I am getting at is being annoyed with updatedb ___saturating___
> > the the disk so easily as the "ancient" method of renicing does not
> > consider the fact that the CPU pwrformance has increased 20-50 fold
> > over disk performace.
> >
> > Bottom line: what about assigning "io niceness" to processes, which
> > would also help with actively scheduling io toward processes
> > needing it.
>
> The problem is that unlike CPU niceness, where you can literally rip the
> CPU away from a hog and give it to some more deserving process, it's not
> as easy to rip an active disk I/O away so somebody else can have it.
>
You can't take the disk away, but you can be careful with it.
The anticipatory scheduler already does that - avoids seeking
away from a read for a while just in case the reader will submit
an adjacent read in short order. (Wonder if it ought to read ahead
a little instead of just waiting?)
Something similiar could be done for io niceness. If we run out of
normal priority io, how about not issuing the low priority io
right away. Anticipate there will be more high-priority io
and wait for some idle time before letting low-priority
requests through. And of course some maximum wait to prevent
total starvation.
> If the updatedb issues a seek/read combo to the disk, and your process gets
> into the I/O queue even 200 nanoseconds later, it *still* has to wait for that
> I/O to finish before it can start its seeks and reads.
>
Anticipatory io niceness might solve that.
> For an extreme example, consider those IDE interfaces where fixating or
> blanking a CD/RW will cause *all* the disks to lock up for the duration.
> No matter how high your priority is, you *cant* get that I/O out the door
> for the next 60-70 seconds unless you're willing to create a coaster.
There's no cure for truely stupid hw. Sometimes I forget why I buy
these expensive scsi drives . . .
Helge Hafting
next prev parent reply other threads:[~2004-02-12 20:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-11 19:04 ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes Jon Burgess
2004-02-11 20:28 ` Rik van Riel
2004-02-11 21:02 ` Michael Frank
2004-02-11 21:18 ` Diego Calleja
2004-02-12 2:00 ` Dave Olien
2004-02-12 2:23 ` Andrea Arcangeli
2004-02-12 9:42 ` ext2/3 performance regression in 2.6 vs 2.4 for small interl Giuliano Pochini
2004-02-12 10:15 ` John Bradford
2004-02-12 10:27 ` Nick Piggin
2004-02-12 17:05 ` Michael Frank
2004-02-12 17:18 ` Valdis.Kletnieks
2004-02-12 20:55 ` Helge Hafting [this message]
2004-02-13 1:57 ` Jamie Lokier
2004-02-13 2:05 ` Nick Piggin
2004-02-12 14:59 ` Andrea Arcangeli
2004-02-13 12:15 ` ext2/3 performance regression in 2.6 vs 2.4 for small interleaved writes Jon Burgess
2004-02-12 10:40 ` Jon Burgess
2004-02-12 20:17 ` Hans Reiser
2004-02-12 9:56 ` Andrew Morton
2004-02-12 20:20 ` Jon Burgess
2004-02-13 8:28 ` Juan Piernas Canovas
2004-02-16 17:51 ` Alex Zarochentsev
2004-02-16 20:03 ` Jon Burgess
2004-02-13 12:35 ` Jon Burgess
2004-02-14 15:00 ` Jon Burgess
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=20040212205503.GA13934@hh.idb.hist.no \
--to=helgehaf@aitel.hist.no \
--cc=Valdis.Kletnieks@vt.edu \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mhf@linuxmail.org \
--cc=piggin@cyberone.com.au \
--cc=pochini@shiny.it \
/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
all inboxes | Powered by JetHome®