linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Turner <pjt@google.com>
To: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, Venki Pallipadi <venki@google.com>,
	Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Mike Galbraith <efault@gmx.de>,
	Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	Ben Segall <bsegall@google.com>, Ingo Molnar <mingo@elte.hu>,
	Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 00/14] sched: entity load-tracking re-work
Date: Fri, 17 Feb 2012 02:48:06 -0800	[thread overview]
Message-ID: <CAPM31RLWpF0mO2faCfY+HOeThz0iW6_7D+S++pGHtJi6hhiAVQ@mail.gmail.com> (raw)
In-Reply-To: <87k43lde0r.fsf@linux.vnet.ibm.com>

On Fri, Feb 17, 2012 at 1:07 AM, Nikunj A Dadhania
<nikunj@linux.vnet.ibm.com> wrote:
> On Wed, 01 Feb 2012 17:38:26 -0800, Paul Turner <pjt@google.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
>


This is almost certainly a result of me twiddling with the weight in
calc_cfs_shares (using average instead of instantaneous weight) in
this version -- see patch 11/14.  While this had some nice stability
properties it was not hot for fairness so I've since reverted it
(snippet attached below).

While it's hard to guarantee it was exactly this since I'm carrying a
few other minor edits in preparation for the next version, the current
results for the next version of this series look like:

8-core:
Starting task group fair16...done
Starting task group fair32...done
Starting task group fair48...done
Waiting for the task to run for 120 secs
Interpreting the results. Please wait....
Time consumed by fair16 cgroup:  316985 Tasks: 16
Time consumed by fair32 cgroup:  320274 Tasks: 32
Time consumed by fair48 cgroup:  320811 Tasks: 48

24-core:
Starting task group fair16...done
Starting task group fair32...done
Starting task group fair48...done
Waiting for the task to run for 120 secs
Interpreting the results. Please wait....
Time consumed by fair16 cgroup:  12628615 Tasks: 96
Time consumed by fair32 cgroup:  12562859 Tasks: 192
Time consumed by fair48 cgroup:  12600364 Tasks: 288

These results are stable and consistent.

As soon as I finish working through Peter's comments I'll upload a
pre-posting so you can re-test if you'd like.  Expect a formal
(non-RFC) posting with other nits such as detangling tracking from
FAIR_GROUP_SCHED so that we may use it more comprehensively following
that within the next week or so.

Thanks,

- Paul

--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -823,7 +823,7 @@ static inline long calc_tg_weight(struct
task_group *tg, struct cfs_rq *cfs_rq)
        */
       tg_weight = atomic64_read(&tg->load_avg);
       tg_weight -= cfs_rq->tg_load_contrib;
-       tg_weight += cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg;
+       tg_weight += cfs_rq->load.weight;


       return tg_weight;
 }
@@ -833,7 +833,7 @@ static long calc_cfs_shares(struct cfs_rq *cfs_rq,
struct task_group *tg)
       long tg_weight, load, shares;

       tg_weight = calc_tg_weight(tg, cfs_rq);
-       load = cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg;
+       load = cfs_rq->load.weight;

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

  reply	other threads:[~2012-02-17 10:48 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02  1:38 [RFC PATCH 00/14] sched: entity load-tracking re-work Paul Turner
2012-02-02  1:38 ` [RFC PATCH 05/14] sched: account for blocked load waking back up Paul Turner
2012-02-16 15:57   ` Peter Zijlstra
2012-02-17 13:00     ` Paul Turner
2012-02-16 16:02   ` Peter Zijlstra
2012-02-17 11:39     ` Paul Turner
2012-02-02  1:38 ` [RFC PATCH 01/14] sched: track the runnable average on a per-task entitiy basis Paul Turner
2012-02-15 23:37   ` Peter Zijlstra
2012-02-17 11:43     ` Paul Turner
2012-02-16 13:27   ` Peter Zijlstra
2012-02-17 11:44     ` Paul Turner
2012-02-02  1:38 ` [RFC PATCH 07/14] sched: compute load contribution by a group entity Paul Turner
2012-02-02  1:38 ` [RFC PATCH 06/14] sched: aggregate total task_group load Paul Turner
2012-02-17  4:41   ` Nikunj A Dadhania
2012-02-17 10:52     ` Paul Turner
2012-02-02  1:38 ` [RFC PATCH 03/14] sched: aggregate load contributed by task entities on parenting cfs_rq Paul Turner
2012-02-02  1:38 ` [RFC PATCH 04/14] sched: maintain the load contribution of blocked entities Paul Turner
2012-02-16 12:25   ` Peter Zijlstra
2012-02-17 11:53     ` Paul Turner
2012-02-02  1:38 ` [RFC PATCH 02/14] sched: maintain per-rq runnable averages Paul Turner
2012-02-02  1:38 ` [RFC PATCH 08/14] sched: normalize tg load contributions against runnable time Paul Turner
2012-02-15 23:36   ` Peter Zijlstra
2012-02-17 12:32     ` Paul Turner
2012-02-20 16:10       ` Peter Zijlstra
2012-02-17 12:34     ` Peter Zijlstra
2012-02-15 23:38   ` Peter Zijlstra
2012-02-02  1:38 ` [RFC PATCH 09/14] sched: maintain runnable averages across throttled periods Paul Turner
2012-02-02  1:38 ` [RFC PATCH 12/14] sched: update_cfs_shares at period edge Paul Turner
2012-02-02  1:38 ` [RFC PATCH 13/14] sched: make __update_entity_runnable_avg() fast Paul Turner
2012-02-06 20:48   ` Peter Zijlstra
2012-02-17 12:49     ` Paul Turner
2012-02-02  1:38 ` [RFC PATCH 11/14] sched: refactor update_shares_cpu() -> update_blocked_avgs() Paul Turner
2012-02-02  1:38 ` [RFC PATCH 14/14] sched: implement usage tracking Paul Turner
2012-02-16 13:37   ` Peter Zijlstra
2012-02-17 10:54     ` Paul Turner
2012-02-20 16:11       ` Peter Zijlstra
2012-02-16 16:58   ` Peter Zijlstra
2012-02-17 11:32     ` Paul Turner
2012-02-20 16:30       ` Peter Zijlstra
2012-02-29 10:37   ` sched per task ARM fix Pantelis Antoniou
2012-02-29 10:37   ` [PATCH 1/2] sched: entity load-tracking re-work - Fix for ARM Pantelis Antoniou
2012-02-28 17:45     ` Morten Rasmussen
2012-02-28 17:52       ` Pantelis Antoniou
2012-02-29 10:37   ` [PATCH 2/2] sched: load-tracking compile when cgroup undefined Pantelis Antoniou
2012-03-13 16:57   ` [RFC PATCH 14/14] sched: implement usage tracking Vincent Guittot
2012-03-14 15:01     ` Peter Zijlstra
2012-03-14 15:45       ` Vincent Guittot
2012-03-14 15:47       ` Paul Turner
2012-03-15 10:52         ` Peter Zijlstra
2012-03-14 15:44     ` Paul Turner
2012-02-02  1:38 ` [RFC PATCH 10/14] sched: replace update_shares weight distribution with per-entity computation Paul Turner
2012-02-06 20:02 ` [RFC PATCH 00/14] sched: entity load-tracking re-work Peter Zijlstra
2012-02-17  9:07 ` Nikunj A Dadhania
2012-02-17 10:48   ` Paul Turner [this message]
2012-02-20  9:41     ` Nikunj A Dadhania
2012-02-21  2:33       ` Paul Turner
2012-02-20 17:01 ` Peter Zijlstra
2012-03-12 10:39 ` Morten Rasmussen
2012-03-13 16:44   ` Paul E. McKenney
2012-03-13 17:08     ` Anca Emanuel
2012-03-13 17:23       ` Paul E. McKenney
2012-03-14  9:03       ` Amit Kucheria
2012-03-14 19:19         ` Paul E. McKenney
2012-03-13 17:28   ` Peter Zijlstra
2012-03-12 10:57 ` Vincent Guittot
2012-03-14 15:59   ` Paul Turner
2012-03-15  9:59     ` Vincent Guittot
2012-04-25 13:07     ` Vincent Guittot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPM31RLWpF0mO2faCfY+HOeThz0iW6_7D+S++pGHtJi6hhiAVQ@mail.gmail.com \
    --to=pjt@google.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=bsegall@google.com \
    --cc=efault@gmx.de \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=vatsa@in.ibm.com \
    --cc=venki@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).