On Tue, Aug 25, 2015 at 11:24:42AM +0200, Ingo Molnar wrote: > > * Paul Turner <pjt@xxxxxxxxxx> wrote: > > > > Anyways, a point here is that threads of the same process competing > > > isn't a new problem. There are many ways to make those threads play > > > nice as the application itself often has to be involved anyway, > > > especially for something like qemu which is heavily involved in > > > provisioning resources. > > > > It's certainly not a new problem, but it's a real one, and it's > > _hard_. You're proposing removing the best known solution. > > Also, just to make sure this is resolved properly, I'm NAK-ing the current > scheduler bits in this series: > > NAKed-by: Ingo Molnar <mingo@xxxxxxxxxx> > > until all of pjt's API design concerns are resolved. This is conceptual, it is not > a 'we can fix it later' detail. > > Tejun, please keep me Cc:-ed to future versions of this series so that I can lift > the NAK if things get resolved. You can add: NAKed-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx> to that. There have been at least 3 different groups of people: - Mike, representing Suse customers - Kamezawa-san, representing Fujitsu customers - Paul, representing Google that claim per-thread control groups are in use and important. Any replacement _must_ provide for this use case up front; its not something that can be cobbled on later. -- 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
