From: Peter Zijlstra <peterz@infradead.org>
To: mingo@kernel.org, linux-kernel@vger.kernel.org
Cc: subhra.mazumdar@oracle.com, steven.sistare@oracle.com,
dhaval.giani@oracle.com, rohit.k.jain@oracle.com,
umgwanakikbuti@gmail.com, matt@codeblueprint.co.uk,
riel@surriel.com, peterz@infradead.org
Subject: [RFC 08/11] sched/fair: Optimize SIS_FOLD
Date: Wed, 30 May 2018 16:22:44 +0200 [thread overview]
Message-ID: <20180530143106.291552903@infradead.org> (raw)
In-Reply-To: 20180530142236.667774973@infradead.org
[-- Attachment #1: peterz-sis-again-11.patch --]
[-- Type: text/plain, Size: 2492 bytes --]
Tracing showed that the per-cpu scanning cost of __select_idle_core()
(~120ns) was significantly higher than that of __select_idle_cpu()
(~40ns).
This means that, even when reduced to the minimal scan, we're still 3x
more expensive than the simple search.
perf annotate suggested this was mostly due to cache-misses on the
additional cpumasks used.
However, we can mitigate this by only doing the more expensive search
when there is a good chance it is beneficial. After all, when there
are no idle cores to be had, there's no point in looking for any
(SMT>2 might want to try without this).
Clearing has_idle_cores early (without an exhaustive search) should be
fine because we're eager to set it when a core goes idle again.
FOLD
1: 0.568188455 seconds time elapsed ( +- 0.40% )
2: 0.643264625 seconds time elapsed ( +- 1.27% )
5: 2.385378263 seconds time elapsed ( +- 1.12% )
10: 3.808555491 seconds time elapsed ( +- 1.46% )
20: 6.431994272 seconds time elapsed ( +- 1.21% )
40: 9.423539507 seconds time elapsed ( +- 2.07% )
FOLD+
1: 0.554694881 seconds time elapsed ( +- 0.42% )
2: 0.632730119 seconds time elapsed ( +- 1.84% )
5: 2.230432464 seconds time elapsed ( +- 1.17% )
10: 3.549957778 seconds time elapsed ( +- 1.55% )
20: 6.118364255 seconds time elapsed ( +- 0.72% )
40: 9.515406550 seconds time elapsed ( +- 1.74% )
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
kernel/sched/fair.c | 5 ++++-
kernel/sched/features.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6382,6 +6382,8 @@ static int __select_idle_core(struct tas
}
}
+ set_idle_cores(target, 0);
+
return best_cpu;
}
@@ -6477,7 +6479,8 @@ static int select_idle_cpu(struct task_s
time = local_clock();
#ifdef CONFIG_SCHED_SMT
- if (sched_feat(SIS_FOLD) && static_branch_likely(&sched_smt_present))
+ if (sched_feat(SIS_FOLD) && static_branch_likely(&sched_smt_present) &&
+ test_idle_cores(target, false))
cpu = __select_idle_core(p, sd, target, nr, &loops);
else
#endif
--- a/kernel/sched/features.h
+++ b/kernel/sched/features.h
@@ -60,7 +60,7 @@ SCHED_FEAT(SIS_PROP, true)
SCHED_FEAT(SIS_AGE, true)
SCHED_FEAT(SIS_ONCE, true)
-SCHED_FEAT(SIS_FOLD, false)
+SCHED_FEAT(SIS_FOLD, true)
/*
* Issue a WARN when we do multiple update_rq_clock() calls
next prev parent reply other threads:[~2018-05-30 14:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 14:22 [RFC 00/11] select_idle_sibling rework Peter Zijlstra
2018-05-30 14:22 ` [RFC 01/11] sched/fair: Fix select_idle_cpu()s cost accounting Peter Zijlstra
2018-05-30 14:22 ` [RFC 02/11] sched/fair: Age the average idle time Peter Zijlstra
2018-05-30 14:22 ` [RFC 03/11] sched/fair: Only use time once Peter Zijlstra
2018-05-30 14:22 ` [RFC 04/11] sched/topology: Introduce sched_domain_cores() Peter Zijlstra
2018-05-30 14:22 ` [RFC 05/11] sched/fair: Re-arrange select_idle_cpu() Peter Zijlstra
2018-05-30 14:22 ` [RFC 06/11] sched/fair: Make select_idle_cpu() proportional to cores Peter Zijlstra
2018-05-30 14:22 ` [RFC 07/11] sched/fair: Fold the select_idle_sibling() scans Peter Zijlstra
2018-05-30 14:22 ` Peter Zijlstra [this message]
2018-05-30 14:22 ` [RFC 09/11] sched/fair: Remove SIS_AVG_PROP Peter Zijlstra
2018-05-30 14:22 ` [RFC 10/11] sched/fair: Remove SIS_AGE/SIS_ONCE Peter Zijlstra
2018-05-30 14:22 ` [RFC 11/11] sched/fair: Remove SIS_FOLD Peter Zijlstra
2018-06-19 22:06 ` [RFC 00/11] select_idle_sibling rework Matt Fleming
2018-06-20 22:20 ` Steven Sistare
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=20180530143106.291552903@infradead.org \
--to=peterz@infradead.org \
--cc=dhaval.giani@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=riel@surriel.com \
--cc=rohit.k.jain@oracle.com \
--cc=steven.sistare@oracle.com \
--cc=subhra.mazumdar@oracle.com \
--cc=umgwanakikbuti@gmail.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 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).