On Sun, Sep 19, 2021 at 06:31:38PM +0800, "yukuai (C)" <yukuai3@xxxxxxxxxx> wrote: > 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. I see where are you coming from now. (Perhaps I'd suggest allocating/prioritizing the allowances on the hosting side. If simply wrapping "everything" into a non-root cgroup is not enough.) On 2021/09/18 3:58, Khazhy Kumykov wrote: > (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). Good point, That's IMO a better idea, it'd be more consistent with other resources for which there exist global (cgroup independent) kernel constraints (e.g. threads-max sysctl, mem= cmdline, cpu hotplug) that double the root cgroup contraint role. OTOH, this also deepens the precedent of init NS root cgroup being special (more special than a container's root cgroup). My .02€, Michal
