Messages in this thread | | | Date | Wed, 18 Oct 2006 11:51:25 +0200 | From | Jens Axboe <> | Subject | Re: Bandwidth Allocations under CFQ I/O Scheduler |
| |
On Wed, Oct 18 2006, 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. > > 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...
While that may make some sense internally, the exported interface would never be workable like that. It needs to be simple, "give me foo kb/sec with max latency bar for this file", with an access pattern or assumed sequential io.
Nobody speaks of iops/sec except some silly benchmark programs. I know that you are describing pseudo-iops, but it still doesn't make it more clear. Things aren't as simple
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |