linux-kernel - cgroup NAKs ignored? Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160312171318.GD1108@gmail.com>
Date:	Sat, 12 Mar 2016 18:13:18 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
Cc:	Tejun Heo <tj@...nel.org>, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, a.p.zijlstra@...llo.nl,
	mingo@...hat.com, lizefan@...wei.com, hannes@...xchg.org,
	pjt@...gle.com, linux-kernel@...r.kernel.org,
	cgroups@...r.kernel.org, linux-api@...r.kernel.org,
	kernel-team@...com, Thomas Gleixner <tglx@...utronix.de>
Subject: cgroup NAKs ignored? Re: [PATCHSET RFC cgroup/for-4.6] cgroup,
 sched: implement resource group and PRIO_RGRP


* Mike Galbraith <umgwanakikbuti@...il.com> 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