[Devel] RE: RFC: I/O bandwidth controller

James.Smart at Emulex.Com James.Smart at Emulex.Com
Tue Aug 12 08:03:24 PDT 2008


Fernando Luis Vázquez Cao wrote:
> > BTW as I said in a previous email, an interesting path to 
> be explored
> > IMHO could be to think in terms of IO time. So, look at the 
> time an IO
> > request is issued to the drive, look at the time the 
> request is served,
> > evaluate the difference and charge the consumed IO time to the
> > appropriate cgroup. Then dispatch IO requests in function of the
> > consumed IO time debts / credits, using for example a token-bucket
> > strategy. And probably the best place to implement the IO time
> > accounting is the elevator.
> Please note that the seek time for a specific IO request is strongly
> correlated with the IO requests that preceded it, which means that the
> owner of that request is not the only one to blame if it 
> takes too long
> to process it. In other words, with the algorithm you propose 
> we may end
> up charging the wrong guy.

I assume all of these discussions are focused on simple storage - disks
direct attached to a single server - and are not targeted at SANs with
arrays, multi-initiator accesses, and fabric/network impacts. True ? 
Such algorithms can be seriously off-base in these latter configurations.

-- james s
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list