From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Morten Rasmussen <Morten.Rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Venki Pallipadi <venki@google.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
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>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Robin Randhawa <Robin.Randhawa@arm.com>
Subject: Re: [RFC PATCH 00/14] sched: entity load-tracking re-work
Date: Tue, 13 Mar 2012 18:28:31 +0100 [thread overview]
Message-ID: <1331659711.18960.86.camel@twins> (raw)
In-Reply-To: <20120312103927.GB25134@e103034-lin.cambridge.arm.com>
On Mon, 2012-03-12 at 10:39 +0000, Morten Rasmussen wrote:
> I have looked at traces of both runnable time and usage time trying to
> understand why you use runnable time as your load metric and not usage
> time which seems more intuitive. What I see is that runnable time
> depends on the total runqueue load. If you have many tasks on the
> runqueue they will wait longer and therefore have higher individual
> load_avg_contrib than they would if the were scheduled across more CPUs.
> Usage time is also affected by the number of tasks on the runqueue as
> more tasks means less CPU time. However, less usage can also just mean
> that the task does not execute very often. This would make a load
> contribution estimate based on usage time less accurate. Is this your
> reason for choosing runnable time?
Exactly so, you cannot ever have more than 100% usage, so no matter how
many tasks you stick on a cpu, you'll never get over that 100% and thus
this is not a usable load metric.
next prev parent reply other threads:[~2012-03-13 17:28 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 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 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 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 07/14] sched: compute load contribution by a group entity 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 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 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 02/14] sched: maintain per-rq runnable averages Paul Turner
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 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 11/14] sched: refactor update_shares_cpu() -> update_blocked_avgs() 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-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-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
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 [this message]
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=1331659711.18960.86.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=Morten.Rasmussen@arm.com \
--cc=Robin.Randhawa@arm.com \
--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=paulmck@linux.vnet.ibm.com \
--cc=pjt@google.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