From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
Doug Smythies <dsmythies@telus.net>,
Rik van Riel <riel@redhat.com>
Subject: Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732
Date: Sun, 10 Apr 2016 11:35:12 +0200 [thread overview]
Message-ID: <1460280912.4251.27.camel@gmail.com> (raw)
In-Reply-To: <CAJZ5v0hDe=pNmWFC6fYADi=vP+WFN+7yvwOZvq_pRMARzUnoiw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
On Sun, 2016-04-10 at 05:44 +0200, Rafael J. Wysocki wrote:
> On Sat, Apr 9, 2016 at 6:39 PM, Mike Galbraith <
> umgwanakikbuti@gmail.com> wrote:
> >
> > Hm, setting gov=performance, and taking the average of 3 30 second
> > interval PkgWatt samples as pipe-test runs..
> >
> > 714KHz/28.03Ws = 25.46
> > 877KHz/30.28Ws = 28.96
> >
> > ..for pipe-test, the tradeoff look a bit more like red than green.
>
> Well, fair enough, but that's just pipe-test, and what about the
> people who don't see the performance gain and see the energy loss,
> like Doug?
Perhaps Doug sees increased power because he's not throttling no_hz,
whereas I am, so he burns more power getting _to_ idle? Dunno, maybe
he'll try the attached. If it's a general case energy loser, so be it,
numbers talk, bs walks and all that ;-)
> Essentially, this trades performance gains in somewhat special
> workloads for increased energy consumption in idle. Those workloads
> need not be run by everybody, but idle is.
Cross core scheduling is routine business, we do truckloads of that for
good reason, and lots of stuff does wakeups at high frequency.
> That said I applied the patch you're complaining about mostly because
> the commit that introduced the change in question in 4.5 claimed that
> it wouldn't affect idle power on systems with reasonably fast C1, but
> that didn't pass the reality test. I'm not totally against restoring
> that change, but it would need to be based on very solid evidence.
Understood. My box seems to be saying we can hug the trees hardest by
telling the CPU get work done as quickly as possible, but I don't have
much experience at tree hugging measurement. Performance wise, tasks
talking via localhost is definitely not special.
tbench 1 2 4 8
base 752 1283 2250 3362
select_idle_sibling() off
735 1344 2080 2884
delta .977 1.047 .924 .857
select_idle_sibling() on, 0c313cb20732 reverted
816 1317 2240 3388
delta 1.085 1.026 .995 1.007 vs base
delta 1.110 .979 1.076 1.174 vs off
(^hm)
-Mike
[-- Attachment #2: sched-throttle-nohz.patch --]
[-- Type: text/x-patch, Size: 1535 bytes --]
sched: ratelimit nohz
Entering nohz code on every micro-idle is too expensive to bear.
Signed-off-by: Mike Galbraith <efault@gmx.de>
---
include/linux/sched.h | 5 +++++
kernel/sched/core.c | 8 ++++++++
kernel/time/tick-sched.c | 2 +-
3 files changed, 14 insertions(+), 1 deletion(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2286,6 +2286,11 @@ static inline int set_cpus_allowed_ptr(s
#ifdef CONFIG_NO_HZ_COMMON
void calc_load_enter_idle(void);
void calc_load_exit_idle(void);
+#ifdef CONFIG_SMP
+extern int sched_needs_cpu(int cpu);
+#else
+static inline int sched_needs_cpu(int cpu) { return 0; }
+#endif
#else
static inline void calc_load_enter_idle(void) { }
static inline void calc_load_exit_idle(void) { }
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -577,6 +577,14 @@ static inline bool got_nohz_idle_kick(vo
return false;
}
+int sched_needs_cpu(int cpu)
+{
+ if (tick_nohz_full_cpu(cpu))
+ return 0;
+
+ return cpu_rq(cpu)->avg_idle < sysctl_sched_migration_cost;
+}
+
#else /* CONFIG_NO_HZ_COMMON */
static inline bool got_nohz_idle_kick(void)
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -676,7 +676,7 @@ static ktime_t tick_nohz_stop_sched_tick
} while (read_seqretry(&jiffies_lock, seq));
ts->last_jiffies = basejiff;
- if (rcu_needs_cpu(basemono, &next_rcu) ||
+ if (sched_needs_cpu(cpu) || rcu_needs_cpu(basemono, &next_rcu) ||
arch_needs_cpu() || irq_work_needs_cpu()) {
next_tick = basemono + TICK_NSEC;
} else {
next prev parent reply other threads:[~2016-04-10 9:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1460092854.4051.1.camel@gmail.com>
[not found] ` <20160408064510.GK3448@twins.programming.kicks-ass.net>
[not found] ` <1460098254.5582.17.camel@gmail.com>
2016-04-08 20:59 ` [regression] cross core scheduling frequency drop bisected to 0c313cb20732 Rafael J. Wysocki
2016-04-08 22:19 ` Doug Smythies
2016-04-09 6:44 ` Mike Galbraith
2016-04-09 7:17 ` Doug Smythies
2016-04-09 7:27 ` Mike Galbraith
2016-04-09 11:08 ` Peter Zijlstra
2016-04-09 6:40 ` Mike Galbraith
2016-04-09 12:33 ` Rafael J. Wysocki
2016-04-09 15:10 ` Mike Galbraith
2016-04-09 16:39 ` Mike Galbraith
2016-04-10 3:44 ` Rafael J. Wysocki
2016-04-10 7:16 ` Doug Smythies
2016-04-10 9:35 ` Mike Galbraith [this message]
2016-04-10 14:54 ` Mike Galbraith
2016-04-09 11:07 ` Peter Zijlstra
2016-04-09 12:31 ` Rafael J. Wysocki
2016-04-10 15:39 ` Mike Galbraith
2016-04-10 20:24 ` Rik van Riel
2016-04-11 3:04 ` Mike Galbraith
2016-04-11 12:38 ` Rik van Riel
2016-04-11 13:21 ` Rafael J. Wysocki
2016-04-11 13:38 ` Rik van Riel
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=1460280912.4251.27.camel@gmail.com \
--to=umgwanakikbuti@gmail.com \
--cc=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=riel@redhat.com \
--cc=rjw@rjwysocki.net \
/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;
as well as URLs for NNTP newsgroup(s).