From: morten.rasmussen@arm.com (Morten Rasmussen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 08/11] sched: get CPU's activity statistic
Date: Wed, 4 Jun 2014 11:25:59 +0100 [thread overview]
Message-ID: <20140604102559.GK29593@e103034-lin> (raw)
In-Reply-To: <CAKfTPtBVyMMzXoFoL=kT8oP97BZ8S6P_2ySNhXLC1gR80jw6vA@mail.gmail.com>
On Wed, Jun 04, 2014 at 10:35:15AM +0100, Vincent Guittot wrote:
> On 4 June 2014 11:23, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Wed, Jun 04, 2014 at 09:55:42AM +0100, Morten Rasmussen wrote:
> >> Both running_avg and runnable_avg are affected by other tasks on the
> >> same cpus, but in different ways. They are equal if you only have one
> >> task on a cpu. If you have more, running_avg will give you the true
> >> requirement of the tasks until the cpu is fully utilized. At which point
> >> the task running_avg will drop if you add more tasks (the unweighted sum
> >> of task running_avgs remains constant).
> >>
> >> runnable_avg on the other hand, might be affected as soon as you have
> >> two task running on the same cpu if they are runnable at the same time.
> >> That isn't necessarily a bad thing for load-balancing purposes, because
> >> tasks that are runnable at the same time are likely to be run more
> >> efficiently by placing them on different cpus. You might view as at sort
> >> of built in concurrency factor, somewhat similar to what Yuyang is
> >> proposing. runnable_avg increases rapidly when the cpu is over-utilized.
> >
> > Agreed.
> >
> >> > I'm not sure I see how 100% is possible, but yes I agree that runnable
> >> > can indeed be inflated due to this queueing effect.
> >>
> >> You should only be able to get to 75% worst case for runnable_avg for
> >> that example. The total running_avg is 50% no matter if the tasks
> >> overlaps or not.
> >
> > Yes, 75% is what I ended up with.
>
> Can you explain how you reach 75% as it depends on the runtime and a
> runtime longer than 345ms will end to a 100% load whatever the
> idletime was previously ?
If the busy period of each task is long enough that the first one to run
runs to completetion before the other task is scheduled you get 25% and
50%. But as I said in my other reply, you can get higher task runnable
if the tasks busy period is long enough that you switch between them
before the first one completes.
next prev parent reply other threads:[~2014-06-04 10:25 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 15:52 [PATCH v2 00/11] sched: consolidation of cpu_power Vincent Guittot
2014-05-23 15:52 ` [PATCH v2 01/11] sched: fix imbalance flag reset Vincent Guittot
2014-05-25 10:33 ` Preeti U Murthy
2014-05-26 7:49 ` Vincent Guittot
2014-05-26 9:16 ` Preeti U Murthy
2014-05-26 10:14 ` Vincent Guittot
2014-05-23 15:52 ` [PATCH v2 02/11] sched: remove a wake_affine condition Vincent Guittot
2014-05-27 12:48 ` Peter Zijlstra
2014-05-27 15:19 ` Vincent Guittot
2014-05-27 15:39 ` Peter Zijlstra
2014-05-27 16:14 ` Vincent Guittot
2014-05-28 6:49 ` Vincent Guittot
2014-05-28 15:09 ` Dietmar Eggemann
2014-05-28 15:25 ` Vincent Guittot
2014-05-27 13:43 ` Peter Zijlstra
2014-05-27 13:45 ` Peter Zijlstra
2014-05-27 15:20 ` Vincent Guittot
2014-05-23 15:52 ` [PATCH v2 03/11] sched: fix avg_load computation Vincent Guittot
2014-05-27 13:48 ` Peter Zijlstra
2014-05-23 15:52 ` [PATCH v2 04/11] sched: Allow all archs to set the power_orig Vincent Guittot
2014-05-30 14:04 ` Dietmar Eggemann
2014-05-30 14:46 ` Peter Zijlstra
2014-05-30 20:50 ` Vincent Guittot
2014-06-04 9:42 ` Dietmar Eggemann
2014-06-04 11:15 ` Vincent Guittot
2014-06-05 8:59 ` Dietmar Eggemann
2014-06-16 9:01 ` Vincent Guittot
2014-06-03 13:22 ` Morten Rasmussen
2014-06-03 14:02 ` Vincent Guittot
2014-06-04 11:17 ` Morten Rasmussen
2014-06-06 7:01 ` Vincent Guittot
2014-05-23 15:52 ` [PATCH v2 05/11] ARM: topology: use new cpu_power interface Vincent Guittot
2014-05-25 13:22 ` Preeti U Murthy
2014-05-26 8:25 ` Vincent Guittot
2014-05-26 9:19 ` Preeti U Murthy
2014-05-23 15:53 ` [PATCH v2 06/11] sched: add per rq cpu_power_orig Vincent Guittot
2014-05-23 15:53 ` [PATCH v2 07/11] Revert "sched: Put rq's sched_avg under CONFIG_FAIR_GROUP_SCHED" Vincent Guittot
2014-05-23 15:53 ` [PATCH v2 08/11] sched: get CPU's activity statistic Vincent Guittot
2014-05-27 17:32 ` Peter Zijlstra
2014-05-28 7:01 ` Vincent Guittot
2014-05-28 12:10 ` Morten Rasmussen
2014-05-28 13:15 ` Vincent Guittot
2014-05-28 15:47 ` Morten Rasmussen
2014-05-28 16:39 ` Vincent Guittot
2014-06-03 12:03 ` Morten Rasmussen
2014-06-03 15:59 ` Peter Zijlstra
2014-06-03 17:41 ` Morten Rasmussen
2014-06-03 15:50 ` Peter Zijlstra
2014-06-03 17:20 ` Morten Rasmussen
2014-06-04 7:47 ` Vincent Guittot
2014-06-04 8:08 ` Peter Zijlstra
2014-06-04 8:55 ` Morten Rasmussen
2014-06-04 9:23 ` Peter Zijlstra
2014-06-04 9:35 ` Vincent Guittot
2014-06-04 10:25 ` Morten Rasmussen [this message]
2014-06-04 9:44 ` Morten Rasmussen
2014-06-04 9:32 ` Vincent Guittot
2014-06-04 10:00 ` Morten Rasmussen
2014-06-04 10:17 ` Peter Zijlstra
2014-06-04 10:36 ` Morten Rasmussen
2014-06-04 10:55 ` Peter Zijlstra
2014-06-04 11:07 ` Vincent Guittot
2014-06-04 11:23 ` Morten Rasmussen
2014-06-04 11:52 ` Vincent Guittot
2014-06-04 13:09 ` Morten Rasmussen
2014-06-04 13:23 ` Morten Rasmussen
2014-05-28 15:17 ` Peter Zijlstra
2014-06-03 15:40 ` Peter Zijlstra
2014-06-03 17:16 ` Morten Rasmussen
2014-06-03 17:37 ` Peter Zijlstra
2014-06-03 17:39 ` Peter Zijlstra
2014-06-03 23:11 ` Yuyang Du
2014-05-30 9:50 ` Dietmar Eggemann
2014-05-30 19:20 ` Vincent Guittot
2014-06-01 11:33 ` Dietmar Eggemann
2014-06-02 14:07 ` Vincent Guittot
2014-05-23 15:53 ` [PATCH v2 09/11] sched: test the cpu's capacity in wake affine Vincent Guittot
2014-05-28 10:58 ` Peter Zijlstra
2014-05-28 11:15 ` Vincent Guittot
2014-11-24 0:34 ` Wanpeng Li
2014-11-24 13:23 ` Vincent Guittot
2014-05-23 15:53 ` [PATCH v2 10/11] sched: move cfs task on a CPU with higher capacity Vincent Guittot
2014-05-29 9:50 ` Peter Zijlstra
2014-05-29 19:37 ` Vincent Guittot
2014-05-30 6:29 ` Peter Zijlstra
2014-05-30 20:05 ` Vincent Guittot
2014-06-02 17:06 ` Vincent Guittot
2014-06-03 11:15 ` Peter Zijlstra
2014-06-03 12:31 ` Vincent Guittot
2014-05-29 14:04 ` Peter Zijlstra
2014-05-29 19:44 ` Vincent Guittot
2014-05-30 13:26 ` Dietmar Eggemann
2014-05-30 19:24 ` Vincent Guittot
2014-05-30 19:45 ` Nicolas Pitre
2014-05-30 20:07 ` Vincent Guittot
2014-05-23 15:53 ` [PATCH v2 11/11] sched: replace capacity by activity Vincent Guittot
2014-05-29 13:55 ` Peter Zijlstra
2014-05-29 19:51 ` Vincent Guittot
2014-06-02 6:21 ` Preeti U Murthy
2014-06-03 9:50 ` Vincent Guittot
2014-05-29 14:02 ` Peter Zijlstra
2014-05-29 19:56 ` Vincent Guittot
2014-05-30 6:34 ` Peter Zijlstra
2014-05-30 19:13 ` Vincent Guittot
2014-05-26 9:44 ` [PATCH v2 00/11] sched: consolidation of cpu_power Preeti U Murthy
2014-05-26 10:04 ` Vincent Guittot
2014-05-26 15:54 ` Vincent Guittot
2014-05-27 5:47 ` Preeti U Murthy
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=20140604102559.GK29593@e103034-lin \
--to=morten.rasmussen@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).