From: Chris Redpath <chris.redpath@arm.com>
To: pjt@google.com, mingo@redhat.com, peterz@infradead.org,
alex.shi@linaro.org, morten.rasmussen@arm.com,
dietmar.eggemann@arm.com
Cc: linux-kernel@vger.kernel.org, Chris Redpath <chris.redpath@arm.com>
Subject: [PATCH 0/2] Per-task load tracking errors
Date: Mon, 9 Dec 2013 12:59:08 +0000 [thread overview]
Message-ID: <1386593950-26475-1-git-send-email-chris.redpath@arm.com> (raw)
Hi Paul, Peter etc.
I've found a couple of bugs in the load tracking code and here
is my attempt to fix them. I have some test code available which
can trigger the issues if anyone is interested.
The first one is straightforward. We can leave a number in
se.avg.decay_count after a short sleep. If that task is later
migrated while runnable, then the left-over decay looks like
unaccounted sleep time so the load is decayed.
The second one is similar. Here we are losing sleep time for a
task if it is migrated while sleeping and the CPU it previously
ran on has entered nohz mode.
I don't really like this fix much, but the root of the problem
is that load tracking more-or-less expects the runqueue's
decay_counter to be up to date, and when nohz is in use it is
not. The fix demonstrates the issue anyway, I haven't seen
other occasions where nohz CPUs distort the tracked load.
Chris Redpath (2):
sched: reset blocked load decay_count during synchronization
sched: update runqueue clock before migrations away
kernel/sched/fair.c | 38 +++++++++++++++++++++++++++++++++-----
1 file changed, 33 insertions(+), 5 deletions(-)
--
1.7.9.5
next reply other threads:[~2013-12-09 12:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 12:59 Chris Redpath [this message]
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
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=1386593950-26475-1-git-send-email-chris.redpath@arm.com \
--to=chris.redpath@arm.com \
--cc=alex.shi@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--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.