Re: Bandwidth Allocations under CFQ I/O Scheduler

[Arjan van de Ven <arjan@infradead.org>]

On Wed, 2006-10-18 at 10:00 +0200, Jakob Oestergaard wrote:
> On Tue, Oct 17, 2006 at 03:23:13PM +0200, Jens Axboe wrote:
> > On Tue, Oct 17 2006, Arjan van de Ven wrote:
> ...
> > > Hi,
> > > 
> > > it's a nice idea in theory. However... since IO bandwidth for seeks is
> > > about 1% to 3% of that of sequential IO (on disks at least), which
> > > bandwidth do you want to allocate? "worst case" you need to use the
> > > all-seeks bandwidth, but that's so far away from "best case" that it may
> > > well not be relevant in practice. Yet there are real world cases where
> > > for a period of time you approach worst case behavior ;(
> > 
> > Bandwidth reservation would have to be confined to special cases, you
> > obviously cannot do it "in general" for the reasons Arjan lists above.
> 
> How about allocating I/O operations instead of bandwidth ?
> 
> So, any read is really a seek+read, and we count that as one I/O
> operation. Same for writes.

Hi,

I can see that that makes it simple, but.. what would it MEAN? Eg what
would a system administrator use it for? It then no longer means "my mp3
player is guaranteed to get the streaming mp3 from the disk at this
bitrate" or something like that... so my question to you is: can you
describe what it'd bring the admin to put such an allocation in place?
If we find that it can be a good approach.. but if not, I'm less certain
this'll be used..

Greetings,
   Arjan van de Ven