Hello, On Thu, May 31, 2018 at 06:16:45PM +0200, Peter Zijlstra wrote: > > So, let's please stay away from it even if that means a bit of > > overhead in terms of interface. > > Urgh, that again :/ Yeah, well, it's pretty important. > I'm still not convinced by your arguments though. The root container can > access all the sub-groups anyway and can grub around in them to take > away resources if it really wants to. That's really messy and if you delegated away a subtree, you can't walk the subtree in a race free way, not easily anyway. > For cpuset in particular randomly restricting on the ancestor level can > create an unrecoverable trainwreck inside a container. Affinities are > not recoverable. Once a runnable task ends up with an empty set, its > affinities are reset and the smaller (empty) set is lost. Yeah, for cpuset, it's messier, but it isn't different from hotunplug scenario, right? I think the best we can do there is putting ancestor operation on an equal footing as hotplug ops. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
