On 07/18/2017 01:28 PM, Peter Zijlstra wrote: > On Mon, Jul 17, 2017 at 10:26:09AM -0400, Tejun Heo wrote: >> Hello, Peter. >> >> On Mon, Jul 17, 2017 at 04:14:09PM +0200, Peter Zijlstra wrote: >>> AFAICT this is not in fact what I suggested... :/ >> Heh, sorry about misattributing that. I was mostly referring to the >> overall idea of marking each cgroup domain or threaded rather than >> subtree. >> >>> My proposal did not have that invalid state. It would simply refuse to >>> change the type from thread to domain in the case where the parent is >>> not a domain. >>> >>> Also, my proposal maintained the normal property inheritance rules. A >>> child cgroup's creation 'type' would be that of its parent and not >>> always be 'domain'. >> But aren't both of the above get weird when the parent can host both >> domain and threaded children? >> >> R >> / >> A(D) >> >> If you create another child B under R, it's naturally gonna be a >> domain. Let's say you turn that to threaded. >> >> R >> / \ >> A(D) B(T) >> >> And now try to create another child C, should that be a domain or >> threaded? > Domain of course, as R must be a domain, and hence all its children > start out as such. > >> If we only inherit from the second level on, which is in itself >> already confusing, that still leads to invalid configs for non-root >> thread roots. > I don't see how. I don't get the example Waiman gave, what is wrong > with: > > R (D) > | > A (D) > / \ > C(D) B(T) > > ? Afaict that's a perfectly valid configuration. >From what I understand, C is considered to be in an invalid state because of the no internal process rule. A in this case is the thread root, so it can have internal process. If C is a domain and a child of A, we will have the case that internal processes in A is competing against cgroup C. I have been advocating (in one of my RFC patches) that we should relax the rules to allow internal processes when only threaded controllers are enabled as they are supposed to be able to handle internal processes. Cheers, Longman -- 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
