[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[dm-devel] RE: RFC: I/O bandwidth controller
- From: James Smart Emulex Com
- To: <fernando oss ntt co jp>, <righi andrea gmail com>
- Cc: xen-devel lists xensource com, containers lists linux-foundation org, linux-kernel vger kernel org, virtualization lists linux-foundation org, dm-devel redhat com, agk sourceware org, baramsori72 gmail com, dave linux vnet ibm com, ngupta google com, balbir linux vnet ibm com
- Subject: [dm-devel] RE: RFC: I/O bandwidth controller
- Date: Tue, 12 Aug 2008 11:03:24 -0400
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]