From: Chris Redpath <chris.redpath@arm.com>
To: "bsegall@google.com" <bsegall@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"pjt@google.com" <pjt@google.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"alex.shi@linaro.org" <alex.shi@linaro.org>,
Morten Rasmussen <Morten.Rasmussen@arm.com>,
Dietmar Eggemann <Dietmar.Eggemann@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Chris Redpath <Chris.Redpath@arm.com>
Subject: Re: [PATCH 2/2] sched: update runqueue clock before migrations away
Date: Wed, 18 Dec 2013 10:13:14 +0000 [thread overview]
Message-ID: <52B1753A.7060501@arm.com> (raw)
In-Reply-To: <xm26vbynmk2y.fsf@sword-of-the-dawn.mtv.corp.google.com>
On 17/12/13 18:03, bsegall@google.com wrote:
> __synchronize_entity_decay will decay load_avg_contrib in order to
> figure out how much to remove from old_cfs_rq->blocked_load.
> update_entity_load_avg will update the underlying runnable_avg_sum/period that
> is used to update load_avg_contrib.
>
> (Normally we update runnable_avg_sum, which updates load_avg_contrib via
> __update_entity_load_avg_contrib. Here we go in the reverse direction
> because we don't hold the right rq locks at the right times.)
>
Thanks Ben, got it now. The only question remaining for me to figure out
is if I need to include the missed tick time in the contrib decay or not
- I definitely need to include it in the negative decay count we send
through a migration. I'll go and check the places we use the removed
load and update blocked load again.
prev parent reply other threads:[~2013-12-18 10:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 12:59 [PATCH 0/2] Per-task load tracking errors Chris Redpath
2013-12-09 12:59 ` [PATCH 1/2] sched: reset blocked load decay_count during synchronization Chris Redpath
2013-12-09 17:59 ` bsegall
2013-12-09 12:59 ` [PATCH 2/2] sched: update runqueue clock before migrations away Chris Redpath
2013-12-09 18:13 ` bsegall
2013-12-10 11:48 ` Peter Zijlstra
2013-12-10 13:24 ` Chris Redpath
2013-12-10 15:14 ` Peter Zijlstra
2013-12-10 15:55 ` Chris Redpath
2013-12-12 18:24 ` Peter Zijlstra
2013-12-13 8:48 ` Vincent Guittot
2013-12-17 14:09 ` Chris Redpath
2013-12-17 15:51 ` Peter Zijlstra
2013-12-17 18:03 ` bsegall
2013-12-18 10:13 ` Chris Redpath [this message]
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=52B1753A.7060501@arm.com \
--to=chris.redpath@arm.com \
--cc=Dietmar.Eggemann@arm.com \
--cc=Morten.Rasmussen@arm.com \
--cc=alex.shi@linaro.org \
--cc=bsegall@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.