Messages in this thread | | | Date | Thu, 11 Mar 2021 14:39:36 -0500 | From | Tejun Heo <> | Subject | Re: [Patch v3 0/2] cgroup: New misc cgroup controller |
| |
Hello,
On Thu, Mar 11, 2021 at 07:58:19PM +0100, Michal Koutný wrote: > > Michal, as you've been reviewing the series, can you please take > > another look and ack them if you don't find anything objectionable? > Honestly, I'm still sitting on the fence whether this needs a new > controller and whether the miscontroller (:-p) is a good approach in the > long term [1].
Yeah, it's a bit of cop-out. My take is that the underlying hardware feature isn't mature enough to have reasonable abstraction built on top of them. Given time, maybe future iterations will get there or maybe it's a passing fad and people will mostly forget about these.
In the meantime, keeping them out of cgroup is one direction, a relatively high friction one but still viable. Or we can provide something of a halfway house so that people who have immediate needs can still leverage the existing infrastructure while controlling the amount of time, energy and future lock-ins they take. So, that's misc controller.
I'm somewhat ambivalent but we've had multiple of these things popping up in the past several years and containment seems to be a reasonable approach at this point.
> [1] Currently, only one thing comes to my mind -- the delegation via > cgroup.subtree_control. The miscontroller may add possibly further > resources whose delegation granularity is bunched up under one entry.
Controller enabling and delegation in themselves aren't supposed to have resource or security implications, so I don't think it's a practical problem.
Thanks.
-- tejun
| |