From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Paul Turner <pjt@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.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>
Subject: Re: [RFC PATCH 14/14] sched: implement usage tracking
Date: Thu, 15 Mar 2012 11:52:21 +0100 [thread overview]
Message-ID: <1331808741.18960.163.camel@twins> (raw)
In-Reply-To: <CAPM31RK6Ft4nPgz0THpjU2Ueq2hTGiGkTsmLdMHK256g1cqozw@mail.gmail.com>
On Wed, 2012-03-14 at 08:47 -0700, Paul Turner wrote:
> On Wed, Mar 14, 2012 at 8:01 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > On Tue, 2012-03-13 at 17:57 +0100, Vincent Guittot wrote:
> >> > struct sched_avg {
> >> > u64 runnable_avg_sum, runnable_avg_period;
> >> > u64 last_runnable_update, decay_count;
> >> > + u32 usage_avg_sum;
> >>
> >> Why usage_avg_sum is 32bits whereas runnable_avg_sum and
> >> runnable_avg_period are 64bits long ? You are doing the same
> >> computation on these 3 variables. Only the computation need to be done
> >> in 64bits but the result could be saved in 32bits ?
> >
> > Since you can never use more than 100% of cpu time, usage_avg_sum is
> > bound to 100% of the period, which (assuming your period < ~4s) should
> > thus still fit in the ~4s u32 provides.
> >
> > Runnable otoh is not bound by that and thus we cannot guarantee the
> > value stays within the ~4s value range.
>
> Actually for runnable we can also make such a guarantee since:
>
> runnable_sum <= \Sum 1024 * k^p --> 1024/(1-k) [geometric series, k<1]
> --> ~48k for our choice of k.
>
> (We do however need 64-bits on any values that accumulate sums of
> loads, e.g. removed_load and *_load_sum.)
Only for the single entry, right? For the aggregated case the runnable
count can be nr_running times your limit, and IIRC (but my brain is
fuzzy since its been a while since I looked at this stuff) you use the
same structure in both cases.
next prev parent reply other threads:[~2012-03-15 10:52 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 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 07/14] sched: compute load contribution by a group entity 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 02/14] sched: maintain per-rq runnable averages 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 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 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 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 [this message]
2012-03-14 15:44 ` 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 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-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
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=1331808741.18960.163.camel@twins \
--to=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=pjt@google.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.com \
--cc=venki@google.com \
--cc=vincent.guittot@linaro.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