On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > But, whatever, let's go there: Given the arguments that I laid out for > the no-internal-tasks rule, how does the problem seem fixable through > relaxing the constraint? Well, for one thing, cpusets would cease to leak CPUs. With the no -internal-tasks constraint, no task can acquire affinity of exclusive set A if set B is an exclusive subset thereof, as there is one and only one spot where the affinity of set A exists: in the forbidden set A. Relaxing no-internal-tasks would fix that, but without also relaxing the process-only rule, cpusets would remain useless for the purpose for which it was created. After all, it doesn't do much good to use the one and only dynamic partitioning tool to partition a box if you cannot subsequently place your tasks/threads properly therein. > What people do now with cgroup inside an application is extremely > limited. Because there is no proper support for it, each use case has > to craft up a dedicated custom setup which is all but guaranteed to be > incompatible with what someone else would come up for another > application. Everybody is in "this is mine, I control the entire > system" mindset, which is fine for those specific setups but > deterimental to making it widely available and useful. IMO, the problem with that making it available to the huddled masses bit is that it is a completely unrealistic fantasy. Can hordes of programs really autonomously carve up a single set of resources? I do not believe they can. The system agent cannot autonomously do so either. Intimate knowledge of local requirements is not optional, it is a prerequisite to sound decision making. You have to have a well defined need before it makes any sense to turn these things on, they are not free, and impact is global. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
