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 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
