Hello, James. On Sat, Aug 20, 2016 at 10:34:14PM -0700, James Bottomley wrote: > I can see that process based is conceptually easier in v2 because you > begin with a process tree, but it would really be a pity to lose the > thread based controls we have now and permanently lose the ability to > create more as we find uses for them. I can't really see how improving > "common resource domain" is a good tradeoff for this. Thread based control for namespace is not a different problem from thread based control for individual applications, right? And the problems with using cgroupfs directly for in-process control still applies the same whether it's system-wide or inside a namespace. One argument could be that inside a namespace, as the cgroupfs is already scoped, cgroup path headaches are less of an issue, which is true; however, that isn't applicable to applications which aren't scoped in thier own namespaces and we can't scope every binary on the system. More importnatly, a given application can't rely on being scoped in a certain way. You can craft a custom config for a specific setup but that's a horrible way to solve the problem of in-application hierarchical resource distribution, and that's what rgroup was all about. 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
