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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel