From: Peter Zijlstra <peterz@infradead.org>
To: Chris Redpath <chris.redpath@arm.com>
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
Subject: Re: [PATCH 2/2] sched: update runqueue clock before migrations away
Date: Tue, 10 Dec 2013 16:14:28 +0100 [thread overview]
Message-ID: <20131210151428.GH12849@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <52A71605.5090509@arm.com>
On Tue, Dec 10, 2013 at 01:24:21PM +0000, Chris Redpath wrote:
> What happens is that if you have a task which sleeps for a while and wakes
> on a different CPU and the previous CPU hasn't had a tick for a while, then
> that sleep time is lost.
/me more confused now.
Where does update_cfs_rq_blocked_load() account sleep time? Its only
concerned with the blocked decay.
Or is it the decay_count <= 0 case in enqueue_entity_load_avg() that's
screwing you over?
That's guestimating the last_runnable_update based on decay_count, and
per the previous the decay count can get slightly out of sync.
If so, we should look to cure the issue enqueue_entity_load_avg() is
trying to work around, namely the fact that we cannot assume synced
clocks, nor can we read remote clocks atomically.
next prev parent reply other threads:[~2013-12-10 15:14 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 [this message]
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
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=20131210151428.GH12849@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Dietmar.Eggemann@arm.com \
--cc=Morten.Rasmussen@arm.com \
--cc=alex.shi@linaro.org \
--cc=bsegall@google.com \
--cc=chris.redpath@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pjt@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 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.