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
