linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Phil Auld <pauld@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>
Subject: [PATCH 0/4] Throttle select_idle_sibling when a target domain is overloaded
Date: Fri, 20 Mar 2020 15:12:41 +0000	[thread overview]
Message-ID: <20200320151245.21152-1-mgorman@techsingularity.net> (raw)

This is a follow-on from the CPU/NUMA load balancer reconcilation
after I noticed that select_idle_sibling() was doing excessive work. It
was originally part of a larger series that merged select_idle_core,
select_idle_sibling and select_idle_cpu as a single pass. Unfortunately,
fixes have invalidated the tests multiple times so this series covers
only one part for now as the tests are extremely time-consuming.

tip/sched/core as of March 13th was used as the baseline with "sched/fair:
fix condition of avg_load calculation" applied which was just picked up
by tip at the time of writing.

Patches 1-2 add schedstats to track the efficiency of
select_idle_sibling(). Ordinarily they are disabled and are only really
of use to a kernel developer. However, I find them more practical to work
with than perf.

Patch 3 is a trivial micro-optimisation that avoids clearing part of
a cpumask if a core has been found.

Patch 4 tracks whether a domain appeared to be overloaded during
select_idle_cpu() so that future scans can abort early if necessary.
This reduces the number of runqueues that are scanned uselessly when
a domain is overloaded.

 include/linux/sched/topology.h |   1 +
 kernel/sched/debug.c           |   6 +++
 kernel/sched/fair.c            | 103 +++++++++++++++++++++++++++++++++++------
 kernel/sched/features.h        |   3 ++
 kernel/sched/sched.h           |   8 ++++
 kernel/sched/stats.c           |   9 ++--
 6 files changed, 113 insertions(+), 17 deletions(-)

-- 
2.16.4


             reply	other threads:[~2020-03-20 15:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20 15:12 Mel Gorman [this message]
2020-03-20 15:12 ` [PATCH 1/4] sched/fair: Track efficiency of select_idle_sibling Mel Gorman
2020-03-23 13:30   ` Valentin Schneider
2020-03-23 13:55     ` Mel Gorman
2020-03-20 15:12 ` [PATCH 2/4] sched/fair: Track efficiency of task recent_used_cpu Mel Gorman
2020-03-23 13:30   ` Valentin Schneider
2020-03-20 15:12 ` [PATCH 3/4] sched/fair: Clear SMT siblings after determining the core is not idle Mel Gorman
2020-03-23 13:31   ` Valentin Schneider
2020-03-20 15:12 ` [PATCH 4/4] sched/fair: Track possibly overloaded domains and abort a scan if necessary Mel Gorman
2020-03-20 15:48   ` Vincent Guittot
2020-03-20 16:44     ` Mel Gorman
2020-03-20 16:54       ` Vincent Guittot
2020-03-20 17:43         ` Mel Gorman
2020-03-24 10:35           ` Vincent Guittot
2020-03-24 11:23             ` Mel Gorman
2020-04-02  7:59   ` [sched/fair] 15e7470dfc: hackbench.throughput 11.2% improvement kernel test robot

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=20200320151245.21152-1-mgorman@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=valentin.schneider@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).