Re: Bandwidth Allocations under CFQ I/O Scheduler

[Jakob Oestergaard <jakob@unthought.net>]

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.

Since the total "capacity" of the system is typically (in real-world
scenarios) the number of operations (seek+X) rather than the raw
sequential bandwidth anyway, I suppose that I/O operations would be what
you wanted to allocate anyway.

Anyway, just a thought...

(And if you're thinking one sequential reader/writer could then starve
the system; well, count every 256KiB of data to read/write as a seperate
I/O operation even though no seek is needed. That would very roughly
match the raw read/write performance with the seek performance)

-- 

 / jakob