* Mike Galbraith <umgwanakikbuti@xxxxxxxxx> wrote: > On Sat, 2016-03-12 at 07:26 +0100, Mike Galbraith wrote: > > On Fri, 2016-03-11 at 10:41 -0500, Tejun Heo wrote: > > > Hello, > > > > > > This patchset extends cgroup v2 to support rgroup (resource group) for > > > in-process hierarchical resource control and implements PRIO_RGRP for > > > setpriority(2) on top to allow in-process hierarchical CPU cycle > > > control in a seamless way. > > > > > > cgroup v1 allowed putting threads of a process in different cgroups > > > which enabled ad-hoc in-process resource control of some resources. > > BTW, within the scheduler, "process" does not exist. [...] Yes, and that's very fundamental. And I see that many bits of the broken 'v2' cgroups ABI already snuck into the upstream kernel in this merge dinwo, without this detail having been agreed upon! :-( Tejun, this _REALLY_ sucks. We had pending NAKs over the design, still you moved ahead like nothing happened, why?! > [...] A high level composite entity is what we currently aggregate from > arbitrary individual entities, a.k.a threads. Whether an individual entity be > an un-threaded "process" bash, a thread of "process" oracle, or one of > "process!?!" kernel is irrelevant. What entity aggregation has to do with > "process" eludes me completely. > > What's ad-hoc or unusual about a thread pool servicing an arbitrary number of > customers using cgroup bean accounting? Job arrives from customer, worker is > dispatched to customer workshop (cgroup), it does whatever on behest of > customer, sends bean count off to the billing department, and returns to the > break room. What's so annoying about using bean counters for.. counting beans > that you want to forbid it? Agreed ... and many others expressed this concern as well. Why were these concerns ignored? Thanks, Ingo -- 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
