Thread (40 messages) 40 messages, 18 authors, 2011-04-02

Re: Preliminary Agenda and Activities for LSF

From: Mike Snitzer <hidden>
Date: 2011-03-29 20:00:02
Also in: dm-devel, linux-fsdevel

On Tue, Mar 29 2011 at  3:13pm -0400,
Shyam_Iyer@dell.com [off-list ref] wrote:
quoted
quoted
quoted
Above is pretty generic. Do you have specific needs/ideas/concerns?

Thanks
Vivek
Yes.. if I limited by Ethernet b/w to 40% I don't need to limit I/O
b/w via cgroups. Such bandwidth manipulations are network switch driven
and cgroups never take care of these events from the Ethernet driver.

So if IO is going over network and actual bandwidth control is taking
place by throttling ethernet traffic then one does not have to specify
block cgroup throttling policy and hence no need for cgroups to be
worried
about ethernet driver events?

I think I am missing something here.

Vivek
Well.. here is the catch.. example scenario..

- Two iSCSI I/O sessions emanating from Ethernet ports eth0, eth1  multipathed together. Let us say round-robin policy.

- The cgroup profile is to limit I/O bandwidth to 40% of the multipathed I/O bandwidth. But the switch may have limited the I/O bandwidth to 40% for the corresponding vlan associated with one of the eth interface say eth1

The computation that the bandwidth configured is 40% of the available bandwidth is false in this case.  What we need to do is possibly push more I/O through eth0 as it is allowed to run at 100% of bandwidth by the switch. 

Now this is a dynamic decision and multipathing layer should take care of it.. but it would need a hint..
No hint should be needed.  Just use one of the newer multipath path
selectors that are dynamic by design: "queue-length" or "service-time".

This scenario is exactly what those path selectors are meant to address.

Mike
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help