On Mon, Jul 10, 2017 at 05:01:19PM -0400, Waiman Long wrote: > On 07/10/2017 04:32 AM, Peter Zijlstra wrote: > > On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote: > >> On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote: > >>> On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote: > >>> IIRC the problem with the 'threaded' marker is that it doesn't clearly > >>> capture what a resource domain is. > >>> > >>> That is, assuming that a thread root is always a resource domain, we get > >>> the following problem: > >>> > >>> If we set 'threaded' on the root group in order to create a thread > >>> (sub)group. If we then want to create another domain group, we'd have to > >>> clear 'threaded' on that. > >>> > >>> R (t=1) > >>> / \ > >>> (t=1) T D (t=0) > >>> > >>> So far so good. However, now we want to create another thread group > >>> under our domain group D, so we have to set its 'threaded' marker again: > >>> > >>> R (t=1) > >>> / \ > >>> (t=1) T D (t=1) > >>> / > >>> T (t=1) > > This configuration is actually not possible with Tejun's latest v3 patch > which took out the "join" operation. Maybe we should keep the "join" > operation if this configuration is likely to happen. Wait what? Why not? That's a fairly fundamental setup that needs to be possible. I understood the 'join' thing was for something else entirely. TJ said the 'join' was to allow thread-roots that were not domain controllers -- which I didn't get the point of. > >>> And we can no longer identify D as a resource domain. If OTOH we mark > >>> 'domain' we get: > >>> > >>> R (d=1) > >>> / \ > >>> (d=0) T D (d=1) > >>> / > >>> T (d=0) > >>> > >>> Which clearly identifies the domains and the thread only groups. > >> So, the difference between the two interfaces is that the one I > >> proposed is marking the thread root which makes all its descendants > >> threaded while the above is marking each individual cgroup as being > >> whether a resource domain or threaded. > > You start by marking the thread root, but then continue to mark all > > 'threaded' (including root). This then leads to the problem described > > above where you cannot (easily) (re)discover what the actual root is. > > I don't think that is true. Internally, we can always find out if a > cgroup is a thread root. Externally, the presence of resource domain > control knobs in a threaded cgroup will indicate that it is a thread root. You're confusing thread root with resource domain. While a resource domain must be a thread root the reverse is not necessarily so (this is what I understood the 'join' thing to be for). And this is detection by inference, which breaks the moment you disable all resource domain controllers, because at that point those files will not be present. > > My proposal differs in that we retain a clear difference between > > resource domain / root and threaded (sub)trees. > > For me, I have no preference of using either the threaded or the domain > marker as long as some kind of join operation that allows the > configuration above is present in the thread mode. They both looks good > to me. It is just a matter of which aspect of the cgroup we want to > emphasize. I would suggest we reach a consensus ASAP and move forward to > other more substantial issues in cgroup v2. I think you're confused on join. Join should not be needed. -- 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
