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 10:28:10 +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:
> 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?


No, not the same.


	R
      / | \
     t1	t2 A
         /   \
        t3   t4


Is fundamentally different from:


             R
	   /   \
	 L       A
       /   \   /   \
      t1  t2  t3   t4


Because if in the first hierarchy you add a task (t5) to R, all of its A
will run at 1/4th of total bandwidth where before it had 1/3rd, whereas
with the second example, if you add our t5 to L, A doesn't get any less
bandwidth.


Please pull your collective heads out of the systemd arse and start
thinking.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ