Re: [RFC PATCH] blk-throttle: enable io throttle for root in cgroup v2

[yukuai (C)]

On 2021/09/18 3:58, Khazhy Kumykov wrote:
> On Fri, Sep 17, 2021 at 10:41 AM Michal Koutný <mkoutny@xxxxxxxx> wrote:
> > Hello Yu.
> >
> > On Thu, Sep 09, 2021 at 10:08:15PM +0800, Yu Kuai <yukuai3@xxxxxxxxxx> wrote:
> > > I'm not sure why this feature is disabled in the first place, is
> > > there any problem or design constraint?
> >
> > The idea for v2 is that in the root cgroup remain only kernel threads that
> > provide "global" services and any user workload that should be
> > constrained is put into non-root cgroups. Additionally, if kernel
> > threads carry out work associated with a cgroup they can charge it to
> > the respective cgroup.
> >
> > [snip]
> > > We want to limit the overall iops/bps of the device in cgroup v2,
> >
> > Cui bono? (I mean what is the reason for throttling on the global level
> > when there's no other entity utiliting the residual?
> > <joke>Your drives are too fast?</joke>)
>
> We'd be interested in something like this as well. (at least for
> io.max). Our use case is providing remote devices which are a shared
> resource. A "global" throttle like this (which is set by a local

Our use case is similair to this, a host can provide several remote
devices to difierent client. If one client is under high io pressure,
other client might be affected. Thus we want to limit the overall
iops/bps from the client.

Thanks,
Kuai

> management daemon) allows for throttling before sending network
> traffic. It's also useful since we can put this throttle on a dm, so
> we can enforce an aggregate throttle without needing backchannels to
> coordinate multiple targets.
> (This does also bring up: if this is a useful thing, would it make
> sense to tie to the device, vs. requiring cgroup. We happen to use
> cgroups so that requirement doesn't affect us).
>
> Khazhy
> > Michal