Re: ext2/3 performance regression in 2.6 vs 2.4 for small interl

[Helge Hafting]

On Thu, Feb 12, 2004 at 12:18:29PM -0500, Valdis.Kletnieks@xxxxxx 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/