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]

Message-ID: <20160407073547.GA12560@cmpxchg.org>
Date:	Thu, 7 Apr 2016 03:35:47 -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 08:45:49AM +0200, Peter Zijlstra wrote:
> So I recently got made aware of the fact that cgroupv2 doesn't allow
> tasks to be associated with !leaf cgroups, this is yet another
> capability of cpu-cgroup you've destroyed.

May I ask how you are using that?

The behavior for tasks in !leaf groups was fairly inconsistent across
controllers because they all did different things, or didn't handle it
at all. For example, the block controller in v1 implements separate
weight knobs for the group as a subtree root as well as for the tasks
only inside the group itself. But it didn't do so for bandwith limits.

The memory controller on the other hand only had a singular set of the
controls that applied to both the local tasks and all subgroups. And I
know Google had a lot of trouble with that because they ended up with
basically uncontrollable leftover cache in the top-level group of some
subtree that would put pressure on the real workload leafgroups below.

There was a lot of back and forth whether we should add a second set
of knobs just to control the local tasks separately from the subtree,
but ended up concluding that the situation can be expressed more
clearly by creating dedicated leaf subgroups for stuff like management
software and launchers instead, so that their memory pools/LRUs are
clearly delineated from other groups and seperately controllable. And
we couldn't think of any meaningful configuration that could not be
expressed in that scheme. I mean, it's the same thing, right? Only
that with tasks in !leaf groups the controller would have to emulate a
hidden leaf subgroup and provide additional interfacing, and without
it the leaf groups are explicit and a single set of knobs suffices.
I.e. it seems more of a convenience thing than actual functionality,
but one that forces ugly redundancy in the interface.

So it was a nice cleanup for the memory controller and I believe the
IO controller as well. I'd be curious how it'd be a problem for CPU?