From: Chris Redpath <chris.redpath@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "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>,
"bsegall@google.com" <bsegall@google.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH 2/2] sched: update runqueue clock before migrations away
Date: Tue, 17 Dec 2013 14:09:13 +0000 [thread overview]
Message-ID: <52B05B09.5090807@arm.com> (raw)
In-Reply-To: <20131212182414.GF2480@laptop.programming.kicks-ass.net>
On 12/12/13 18:24, Peter Zijlstra wrote:
> Would pre_schedule_idle() -> rq_last_tick_reset() -> rq->last_sched_tick
> be useful?
>
> I suppose we could easily lift that to NO_HZ_COMMON.
>
Many thanks for the tip Peter, I have tried this out and it does provide
enough information to be able to correct the problem. The new version
doesn't update the rq, just carries the extra unaccounted time
(estimated from the jiffies) over to be processed during enqueue.
However before I send a new patch set I have a question about the
existing behavior. Ben, you may already know the answer to this?
During a wake migration we call __synchronize_entity_decay in
migrate_task_rq_fair, which will decay avg.runnable_avg_sum. We also
record the amount of periods we decayed for as a negative number in
avg.decay_count.
We then enqueue the task on its target runqueue, and again we decay the
load by the number of periods it has been off-rq.
if (unlikely(se->avg.decay_count <= 0)) {
se->avg.last_runnable_update = rq_clock_task(rq_of(cfs_rq));
if (se->avg.decay_count) {
se->avg.last_runnable_update -= (-se->avg.decay_count)
<< 20;
>>> update_entity_load_avg(se, 0);
Am I misunderstanding how this is supposed to work or have we been
always double-accounting sleep time for wake migrations?
next prev parent reply other threads:[~2013-12-17 14:09 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 [this message]
2013-12-17 15:51 ` Peter Zijlstra
2013-12-17 18:03 ` bsegall
2013-12-18 10:13 ` Chris Redpath
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=52B05B09.5090807@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox