linux-kernel - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <1457802262.3628.129.camel@gmail.com>
Date:	Sat, 12 Mar 2016 18:04:22 +0100
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	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
Cc:	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	linux-api@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource
 group and PRIO_RGRP

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.  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?

	-Mike