On Mon, 2018-03-19 at 17:41 -0400, Waiman Long wrote: > On 03/19/2018 04:49 PM, Mike Galbraith wrote: > > On Mon, 2018-03-19 at 08:34 -0700, Tejun Heo wrote: > >> Hello, Mike. > >> > >> On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote: > >>> Under the hood v2 details are entirely up to you. My input ends at > >>> please don't leave dynamic partitioning standing at the dock when v2 > >>> sails. > >> So, this isn't about implementation details but about what the > >> interface achieves - ie, what's the actual function? The only thing I > >> can see is blocking the entity which is configuring the hierarchy from > >> making certain configs. While that might be useful in some specific > >> use cases, it seems to miss the bar for becoming its own kernel > >> feature. After all, nothing prevents the same entity from clearing > >> the exlusive bit and making the said changes. > > Yes, privileged contexts can maliciously or stupidly step all over one > > other no matter what you do (finite resource), but oxymoron creation > > (CPUs simultaneously balanced and isolated) should be handled. If one > > context can allocate a set overlapping a set another context intends to > > or already has detached from scheduler domains, both are screwed. > > > > -Mike > > The allocations of CPUs to child cgroups should be controlled by the > parent cgroup. It is the parent's fault if some CPUs are in both > balanced and isolated cgroups. > > How about we don't allow turning off scheduling if the CPUs aren't > exclusive from the parent's perspective? So you can't create an isolated > cgroup if the CPUs aren't exclusive. Will this be a good enough compromise? Sure. The kernel need only ensure its own sanity. Userspace conflicts are more or less a non-issue. In practice, all players but one will have been constrained or eliminated prior to any partitioning. -Mike -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
