From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Ingo Molnar <mingo@kernel.org>
Cc: Paul Turner <pjt@google.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
Venki Pallipadi <venki@google.com>,
Ben Segall <bsegall@google.com>, Mike Galbraith <efault@gmx.de>,
Vincent Guittot <vincent.guittot@linaro.org>,
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
Morten Rasmussen <Morten.Rasmussen@arm.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Namhyung Kim <namhyung@kernel.org>
Subject: Re: sched: per-entity load-tracking
Date: Mon, 08 Oct 2012 14:14:45 +0200 [thread overview]
Message-ID: <1349698485.7880.6.camel@twins> (raw)
In-Reply-To: <20121006073947.GA26538@gmail.com>
On Sat, 2012-10-06 at 09:39 +0200, Ingo Molnar wrote:
Thanks Ingo! Paul,
> tip/kernel/sched/fair.c | 28 ++++++++++++++++++----------
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> Index: tip/kernel/sched/fair.c
> ===================================================================
> --- tip.orig/kernel/sched/fair.c
> +++ tip/kernel/sched/fair.c
>
> @@ -1151,7 +1156,7 @@ static inline void update_cfs_shares(str
> * Note: The tables below are dependent on this value.
> */
> #define LOAD_AVG_PERIOD 32
> -#define LOAD_AVG_MAX 47765 /* maximum possible load avg */
> +#define LOAD_AVG_MAX 47742 /* maximum possible load avg */
> #define LOAD_AVG_MAX_N 345 /* number of full periods to produce LOAD_MAX_AVG */
>
> /* Precomputed fixed inverse multiplies for multiplication by y^n */
> @@ -1203,7 +1208,8 @@ static __always_inline u64 decay_load(u6
> }
>
> val *= runnable_avg_yN_inv[local_n];
> - return SRR(val, 32);
> + /* We don't use SRR here since we always want to round down. */
> + return val >> 32;
> }
>
> /*
This is from patches/sched-fast_decay.patch and I changed both the
patch and the changelog to reflect your changes.
>@@ -262,6 +262,9 @@ static inline struct cfs_rq *group_cfs_r
> return grp->my_q;
> }
>
> +static void update_cfs_rq_blocked_load(struct cfs_rq *cfs_rq,
> + int force_update);
> +
> static inline void list_add_leaf_cfs_rq(struct cfs_rq *cfs_rq)
> {
> if (!cfs_rq->on_list) {
> @@ -281,6 +284,8 @@ static inline void list_add_leaf_cfs_rq(
> }
>
> cfs_rq->on_list = 1;
> + /* We should have no load, but we need to update last_decay. */
> + update_cfs_rq_blocked_load(cfs_rq, 0);
> }
> }
This seems to have come from patches/sched-cfs_rq_blocked_load.patch, and I merged
it in there. With subsequent updates in
patches/sched-wakeup_load.patch. I didn't find any changes to the Changelogs for either.
> @@ -4236,13 +4242,15 @@ static void __update_blocked_averages_cp
> if (se) {
> update_entity_load_avg(se, 1);
> /*
> - * We can pivot on the runnable average decaying to zero for
> - * list removal since the parent average will always be >=
> - * child.
> + * We pivot on our runnable average having decayed to zero for
> + * list removal. This generally implies that all our children
> + * have also been removed (modulo rounding error or bandwidth
> + * control); however, such cases are rare and we can fix these
> + * at enqueue.
> + *
> + * TODO: fix up out-of-order children on enqueue.
> */
> - if (se->avg.runnable_avg_sum)
> - update_cfs_shares(cfs_rq);
> - else
> + if (!se->avg.runnable_avg_sum && !cfs_rq->nr_running)
> list_del_leaf_cfs_rq(cfs_rq);
> } else {
> struct rq *rq = rq_of(cfs_rq);
This hunk seems to have come from
patches/sched-swap_update_shares.patch, merged in there, no Changelog
changes afaict.
I've updated my queue (at the usual location:
http://programming.kicks-ass.net/sekrit/patches.tar.bz2), Paul please
verify I didn't miss anything.
next prev parent reply other threads:[~2012-10-08 12:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 20:52 sched: per-entity load-tracking Paul Turner
2012-10-06 3:27 ` Paul Turner
2012-10-06 7:39 ` Ingo Molnar
2012-10-08 12:14 ` Peter Zijlstra [this message]
2012-10-09 18:29 ` Paul Turner
2012-10-09 18:35 ` Paul Turner
-- strict thread matches above, loose matches on Subject: below --
2012-06-28 3:36 Paul Turner
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=1349698485.7880.6.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=Morten.Rasmussen@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=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=nikunj@linux.vnet.ibm.com \
--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 \
--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