linux-kernel - Re: [RFC PATCH 00/14] sched: entity load-tracking re-work

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: <87k43lde0r.fsf@linux.vnet.ibm.com>
Date:	Fri, 17 Feb 2012 14:37:16 +0530
From:	Nikunj A Dadhania <nikunj@...ux.vnet.ibm.com>
To:	Paul Turner <pjt@...gle.com>, linux-kernel@...r.kernel.org
Cc:	Venki Pallipadi <venki@...gle.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	Ben Segall <bsegall@...gle.com>, Ingo Molnar <mingo@...e.hu>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH 00/14] sched: entity load-tracking re-work

On Wed, 01 Feb 2012 17:38:26 -0800, Paul Turner <pjt@...gle.com> wrote:
> Hi all,
> 
> The attached series is an RFC on implementing load tracking at the entity
> instead of cfs_rq level. This results in a bottom-up load-computation in which
> entities contribute to their parents load, as opposed to the current top-down
> where the parent averages its children.  In particular this allows us to
> correctly migrate load with their accompanying entities and provides the
> necessary inputs for intelligent load-balancing and power-management.
> 
> It was previously well tested and stable, but that was on v3.1-; there's been
> some fairly extensive changes in the wake-up path since so apologies if anything
> was broken in the rebase.Note also, since this is also an RFC on the approach I
> have not yet de-linted the various CONFIG combinations for introduced compiler
> errors.
> 

I gave a quick run to this series, and it seems the fairness across
taskgroups is broken with this.

Test setup:
Machine : IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8
core, 64GB RAM, 16 cpu.

Create 3 taskgroups: fair16, fair32 and fair48 having 16, 32 and 48
cpu-hog tasks respectively. They have equal shares(default 1024), so
they should consume roughly the same time.

120secs run 1:
Time consumed by fair16 cgroup:  712912 Tasks: 16
Time consumed by fair32 cgroup:  650977 Tasks: 32
Time consumed by fair48 cgroup:  575681 Tasks: 48

120secs run 2:
Time consumed by fair16 cgroup:  686295 Tasks: 16
Time consumed by fair32 cgroup:  643474 Tasks: 32
Time consumed by fair48 cgroup:  611415 Tasks: 48

600secs run 1:
Time consumed by fair16 cgroup:  4109678 Tasks: 16
Time consumed by fair32 cgroup:  1743983 Tasks: 32
Time consumed by fair48 cgroup:  3759826 Tasks: 48

600secs run 2:
Time consumed by fair16 cgroup:  3893365 Tasks: 16
Time consumed by fair32 cgroup:  3028280 Tasks: 32
Time consumed by fair48 cgroup:  2692001 Tasks: 48

As you can see there is a lot of variance in the above results.

wo patches
120secs run 1:
Time consumed by fair16 cgroup:  667644 Tasks: 16
Time consumed by fair32 cgroup:  653771 Tasks: 32
Time consumed by fair48 cgroup:  624915 Tasks: 48

600secs run 1:
Time consumed by fair16 cgroup:  3278425 Tasks: 16
Time consumed by fair32 cgroup:  3140335 Tasks: 32
Time consumed by fair48 cgroup:  3198817 Tasks: 48

Regards
Nikunj


Download attachment "fair.sh" of type "application/x-sh" (793 bytes)