Hey, On Wed, Jun 21, 2017 at 05:50:09PM -0400, Waiman Long wrote: > >> I think CPU isn't a good example for that. > > Can you please elaborate? > > CPU is probably the most prominent controller where deep hierarchy has a > performance cost. So I can't envision that it will forbid internal > process competition. I think there's a fundamental misunderstanding here. The internal competion thing is about how to account for resource consumptions which aren't tied to specific processes or tasks. Thread mode allows building sub-hierarchy beyond the domain point while still keeping the domain at the root of the thread subtree. It is true that as currently implemented, CPU controller has performance issues for some workloads even with a moderate level of nesting (and quite a bit of other artifacts from nesting too); however, supporting control of anonymous resources or not is an orthogonal issue. People can enable thread mode at the root if that's applicable to the workload at hand but you can't change what the basic topology means because a controller has performance overhead. > >> Another alternative is to treat no internal process as a controller > >> attribute. Then we don't need to worry about this intricate question and > >> let the controllers decide if they will allow internal processes. > > Isn't that what "threaded" is? > > That is exactly what this patch intends to do. However, you raised > concern that threaded may not be equivalent to the need of allowing > internal process. That is why I propose that. If your concern is only > about the documentation change, we can certainly fix that. I'm really lost on what this actually achieves. Can we please first talk about what you're trying to enable? Let's talk about features and capabilities first because it feels like most of the changes in this patchset lack them and we seem to be talking past each other. Thanks. -- tejun -- 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
