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
