From: Sai Gurrappadi <sgurrappadi@nvidia.com>
To: "rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>
Cc: Peter Boonstoppel <pboonstoppel@nvidia.com>,
Peter Zijlstra <peterz@infradead.org>,
Colin Cross <ccross@android.com>,
Arjan van de Ven <arjan@linux.intel.com>,
linux-pm@vger.kernel.org
Subject: [RFC] sched/core: Fix up load metric exposed to cpuidle
Date: Fri, 23 Sep 2016 14:49:47 -0700 [thread overview]
Message-ID: <57E5A37B.8010802@nvidia.com> (raw)
When triaging a performance degradation of ~5% on some use cases between
our k3.18 and k4.4 trees, we found that the menu cpuidle governor on k4.4
was way more aggressive when requesting for deeper idle states. It would
often get it wrong though resulting in perf loss.
The menu governor tries to bias picking shallower idle states based on the
historical load on the CPU. The busier the CPU, the shallower the idle
state.
However, after commit "3289bdb sched: Move the loadavg code to a more
obvious location", the load metric it looks at is rq->load.weight which is
the instantaneous se->load.weight sum for top level entities on the rq
which on idle entry is always 0 (for the common case at least) because
there is nothing on the cfs rq.
The previous metric the menu governor used was rq->cpu_load[0] which is a
snap shot of the weighted_cpuload at the previous load update point so it
isn't always 0 on idle entry.
Unfortunately, it isn't straightforward to switch the metric being used to
rq->cfs.load_avg or rq->cfs.util_avg because they overestimate the load a
lot more than rq->cpu_load[0] (include blocked task contrib.). That would
potentially require redoing the magic constants in the menu governor's
performance_multiplier...so for now, use rq->cpu_load[0] instead to
preserve old behaviour.
Reported-by: Juha Lainema <jlainema@nvidia.com>
Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
---
* I realize this might not be the best thing to do hence the RFC tag.
Thoughts?
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44817c6..d1aea12 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2955,7 +2955,7 @@ void get_iowait_load(unsigned long *nr_waiters, unsigned long *load)
{
struct rq *rq = this_rq();
*nr_waiters = atomic_read(&rq->nr_iowait);
- *load = rq->load.weight;
+ *load = rq->cpu_load[0];
}
#ifdef CONFIG_SMP
--
2.1.4
next reply other threads:[~2016-09-23 21:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 21:49 Sai Gurrappadi [this message]
2016-09-23 22:06 ` [RFC] sched/core: Fix up load metric exposed to cpuidle Peter Zijlstra
2016-09-23 22:44 ` Sai Gurrappadi
2016-09-29 13:22 ` Rafael J. Wysocki
2016-09-29 18:22 ` Sai Gurrappadi
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=57E5A37B.8010802@nvidia.com \
--to=sgurrappadi@nvidia.com \
--cc=arjan@linux.intel.com \
--cc=ccross@android.com \
--cc=linux-pm@vger.kernel.org \
--cc=pboonstoppel@nvidia.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.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.