From: Mel Gorman <mgorman@techsingularity.net>
To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
Li Aubrey <aubrey.li@linux.intel.com>,
Qais Yousef <qais.yousef@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Mel Gorman <mgorman@techsingularity.net>
Subject: [PATCH v4 0/4] Scan for an idle sibling in a single pass
Date: Mon, 25 Jan 2021 08:59:05 +0000 [thread overview]
Message-ID: <20210125085909.4600-1-mgorman@techsingularity.net> (raw)
Changelog since v3
o Drop scanning based on cores, SMT4 results showed problems
Changelog since v2
o Remove unnecessary parameters
o Update nr during scan only when scanning for cpus
Changlog since v1
o Move extern declaration to header for coding style
o Remove unnecessary parameter from __select_idle_cpu
This series of 4 patches reposts three patches from Peter entitled
"select_idle_sibling() wreckage". It only scans the runqueues in a single
pass when searching for an idle sibling.
Three patches from Peter were dropped. The first patch altered how scan
depth was calculated. Scan depth deletion is a random number generator
with two major limitations. The avg_idle time is based on the time
between a CPU going idle and being woken up clamped approximately by
2*sysctl_sched_migration_cost. This is difficult to compare in a sensible
fashion to avg_scan_cost. The second issue is that only the avg_scan_cost
of scan failures is recorded and it does not decay. This requires deeper
surgery that would justify a patch on its own although Peter notes that
https://lkml.kernel.org/r/20180530143105.977759909@infradead.org is
potentially useful for an alternative avg_idle metric.
The second patch dropped scanned based on cores instead of CPUs as it
rationalised the difference between core scanning and CPU scanning.
Unfortunately, Vincent reported problems with SMT4 so it's dropped
for now until depth searching can be fixed.
The third patch dropped converted the idle core scan throttling mechanism
to SIS_PROP. While this would unify the throttling of core and CPU
scanning, it was not free of regressions and has_idle_cores is a fairly
effective throttling mechanism with the caveat that it can have a lot of
false positives for workloads like hackbench.
Peter's series tried to solve three problems at once, this subset addresses
one problem.
losses but won more than it lost across a range of workloads and machines.
kernel/sched/fair.c | 153 +++++++++++++++++++---------------------
kernel/sched/features.h | 1 -
2 files changed, 72 insertions(+), 82 deletions(-)
--
2.26.2
next reply other threads:[~2021-01-26 5:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 8:59 Mel Gorman [this message]
2021-01-25 8:59 ` [PATCH 1/4] sched/fair: Remove SIS_AVG_CPU Mel Gorman
2021-01-25 8:59 ` [PATCH 2/4] sched/fair: Move avg_scan_cost calculations under SIS_PROP Mel Gorman
2021-01-27 10:39 ` Vincent Guittot
2021-01-25 8:59 ` [PATCH 3/4] sched/fair: Remove select_idle_smt() Mel Gorman
2021-01-27 10:39 ` Vincent Guittot
2021-02-17 13:17 ` [tip: sched/core] " tip-bot2 for Mel Gorman
2021-01-25 8:59 ` [PATCH 4/4] sched/fair: Merge select_idle_core/cpu() Mel Gorman
2021-01-27 10:43 ` Vincent Guittot
2021-01-27 12:02 ` Mel Gorman
2021-01-27 13:07 ` Vincent Guittot
2021-01-27 13:21 ` Mel Gorman
2021-01-27 13:26 ` Vincent Guittot
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=20210125085909.4600-1-mgorman@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=aubrey.li@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=vincent.guittot@linaro.org \
/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).