linux-kernel - Re: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?

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, 15 May 2014 13:57:51 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Michael wang <wangyun@...ux.vnet.ibm.com>
Cc:	Rik van Riel <riel@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>, Mike Galbraith <efault@....de>,
	Alex Shi <alex.shi@...aro.org>, Paul Turner <pjt@...gle.com>,
	Mel Gorman <mgorman@...e.de>,
	Daniel Lezcano <daniel.lezcano@...aro.org>
Subject: Re: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?

On Thu, May 15, 2014 at 05:35:25PM +0800, Michael wang wrote:
> On 05/15/2014 05:06 PM, Peter Zijlstra wrote:
> [snip]
> >> However, when the group level is too deep, that doesn't works any more...
> >>
> >> I'm not sure but seems like 'deep group level' and 'vruntime bonus for
> >> sleeper' is the keep points here, will try to list the root cause after
> >> more investigation, thanks for the hints and suggestions, really helpful ;-)
> > 
> > How deep is deep? You run into numerical problems quite quickly, esp.
> > when you've got lots of CPUs. We've only got 64bit to play with, that
> > said there were some patches...
> 
> It's like:
> 
> 	/cgroup/cpu/l1/l2/l3/l4/l5/l6/A
> 
> about level 7, the issue can not be solved any more.

That's pretty retarded and yeah, that's way past the point where things
make sense. You might be lucky and have l1-5 as empty/pointless
hierarchy so the effective depth is less and then things will work, but
*shees*..

> > -#if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage under light load  */
> > +#if 1 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage under light load  */
> 
> That is trying to solve the load overflow issue, correct?
> 
> I'm not sure which account will turns to be huge when group get deeper,
> the load accumulation will suffer discount when passing up, isn't it?
> 

It'll use 20 bits for precision instead of 10, so it gives a little more
'room' for deeper hierarchies/big cpu-count.

All assuming you're running 64bit kernels of course.

Content of type "application/pgp-signature" skipped