Re: Bandwidth Allocations under CFQ I/O Scheduler

[Jens Axboe]

On Wed, Oct 18 2006, Nick Piggin wrote:
> Jens Axboe wrote:
> >On Wed, Oct 18 2006, Alan Cox wrote:
> >
> >>Bandwidth is completely silly in this context, iops/sec is merely
> >>hopeless 8)
> >
> >
> >Both need the disk to play nicely, if you get into error handling or
> >correction, you get screwed. Bandwidth by itself is meaningless, you
> >need latency as well to make sense of it.
> 
> When writing an IO scheduler, I decided `time' was a pretty good
> metric. That's roughly what we use for CPU scheduling as well (but
> use nice levels and adjusted by dynamic priorities instead of a
> straight % share).

Precisely, hence CFQ is now based on the time metric. Given larger
slices, you can mostly eliminate the impact of other applications in the
system.

> So you could say you want your database to consume no more than 50%
> of disk and have your mp3 player get a minimum of 10%. Of course,
> that doesn't say anything about what the time slices are, or what
> latencies you can expect (1s out of every 10, or 100ms out of every
> 1000?).

As I wrote previously, both a percentage and bandwidth  along with
desired latency make sense. For the mp3 player, you probably don't care
how much of the system it uses. You want 256kbit/sec or whatever you
media is, and if you don't get that then things don't work. The other
scenario is limiting eg the database.

> It is still far from perfect, but at least it accounts for seeks vs
> throughput reasonably well, and in a device independent manner.

We can't aim for perfection, as that is simple not doable generically.
So we have to settle for something that makes sense and is enforcible to
some extent. We can limit something to foo percentage of the disk, and
we can try the hardest possible to satisfy the mp3 player as long as we
know what it requires. Right now we don't, so we treat everybody the
same wrt slices and latency.

-- 
Jens Axboe

-
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/