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: <20160407080833.GK3430@twins.programming.kicks-ass.net>
Date:	Thu, 7 Apr 2016 10:08:33 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Johannes Weiner <hannes@...xchg.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 03:35:47AM -0400, Johannes Weiner wrote:
> 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?

_I_ use a kernel with CONFIG_CGROUPS=n (yes really).

But seriously? You have to ask?

The root cgroup is per definition not a leaf, and all tasks start life
there, and some cannot be ever moved out.

Therefore _everybody_ uses this.

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

Then they're all bloody broken, because fully hierarchical was an early
requirement for cgroups; I know, because I had to throw away many days
of work and start over with cgroup support when they did that.

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

The full hierarchy took years to make work and is fully ingrained with
how the thing words, changing it isn't going to be nice or easy.


So sure, go with a lowest common denominator, instead of fixing shit,
yay for progress :/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ