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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 7 Apr 2016 16:23:44 -0400
From:	Johannes Weiner <hannes@...xchg.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Tejun Heo <tj@...nel.org>, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, mingo@...hat.com, lizefan@...wei.com,
	pjt@...gle.com, 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 Thu, Apr 07, 2016 at 09:31:27PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:04:24PM -0400, Johannes Weiner wrote:
> 
> > All this means here is that if you want to change the shares allocated
> > to the tasks in R (or then L) you have to be explicit about it and
> > update the weight configuration in L.
> 
> Updating the weight of L for every task spawned and killed is simply not
> an option.
> 
> The fact that you're not willing to admit to this is troubling, but does
> confirm I can stop spending time on anything cgroup v2. cpu-cgroup just
> isn't going to move to this inferior interface.

I guess I walked right into that one, didn't I ;-) It probably makes
more sense to discuss a real-life workload instead of a diagram.

Obviously, if the threadpool size is highly variable it's not
reasonable to ask the user to track every update and accordingly
reconfigure the controller. I fully agree with you there.

All I meant to point out is that the *implicit* behavior of the v1
interface did create real problems, to show you that this is not a
one-sided discussion and that there are real life concerns that played
into the decision of not letting loose tasks compete with groups.

If this is a real workload rather than a thought experiment, it will
need to be supported in v2 as well - just if we can help it hopefully
without reverting to the tricky behavior of the v1 controller. One
possible solution I could imagine for example is adding the option to
configure a groups weight such that its dynamically based on the # of
threads. But it depends on what the exact requirements are here.

Could you explain what this workload is so it's easier to reason about?

Mike, is that the one you referred to with one group per customer
account? If so, would you have a pointer to where you outline it?