[dm-devel] Preliminary Agenda and Activities for LSF
Mike Snitzer
snitzer at redhat.com
Tue Mar 29 19:59:53 UTC 2011
On Tue, Mar 29 2011 at 3:13pm -0400,
Shyam_Iyer at dell.com <Shyam_Iyer at dell.com> wrote:
> > > > 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
More information about the dm-devel
mailing list