| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: RFC: I/O bandwidth controller
|
To: |
<fernando@xxxxxxxxxxxxx>, <righi.andrea@xxxxxxxxx> |
|
Subject: |
[Xen-devel] RE: RFC: I/O bandwidth controller |
|
From: |
James.Smart@xxxxxxxxxx |
|
Date: |
Tue, 12 Aug 2008 11:03:24 -0400 |
|
Cc: |
xen-devel@xxxxxxxxxxxxxxxxxxx, containers@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, taka@xxxxxxxxxxxxx, dm-devel@xxxxxxxxxx, agk@xxxxxxxxxxxxxx, baramsori72@xxxxxxxxx, dave@xxxxxxxxxxxxxxxxxx, ngupta@xxxxxxxxxx, balbir@xxxxxxxxxxxxxxxxxx |
|
Delivery-date: |
Tue, 12 Aug 2008 08:14:04 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<1218117578.11703.81.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx><48A0A689.40908@xxxxxxxxx> <loom.20080812T071504-212@xxxxxxxxxxxxxx><20080812.201025.57762305.taka@xxxxxxxxxxxxx><48A18854.9020000@xxxxxxxxx> <48A18B1F.6080000@xxxxxxxxx> <1218549276.4456.100.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
Acj8g14F+MzS3/B+SNmfCy2Vprl+TAAB5/qQ |
|
Thread-topic: |
RFC: I/O bandwidth controller |
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
|
|
|
| |
|
Home