All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, Mike Galbraith <efault@gmx.de>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Giovanni Gherdovich <ggherdovich@suse.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>
Subject: [PATCH 0/6] Reduce migrations and conflicts with automatic NUMA balancing v2
Date: Tue, 13 Feb 2018 13:37:24 +0000	[thread overview]
Message-ID: <20180213133730.24064-1-mgorman@techsingularity.net> (raw)

This is a combination of "Reduce migrations due to load imbalance and
process exits" and "Stop wake_affine fighting with automatic NUMA balancing"
series.

There was a request for data on NAS OMP and how it compares with hard-binding
of threads to CPUs that is included in the changelog for the relevant
patch. I did not update most of the comparisons as a partial rerun of the
workloads shows similar results.

Changelog since v1
o Replace patch 4 with Peter's version
o Correct comments
o Add data on NAS OMP
o Rebase to 4.16-rc1

The following series was motivated by the fact that higher migrations were
observed than expected. The first two patches are minor cleanups. The third
patch avoids migrations on wakeup when two CPUs are equally loaded which is
particularly important in the case where the measured load is 0. The fourth
patch avoids cross-node migrations of a parent process when the child exits.
The fifth path resists new children being woken for the first time on a
remote node but it's not barred completely as that may lead to saturation
of a single node. The final patch forces automatic NUMA balancing to backoff
if it disagrees with wake_affine about where a task should be running.

 kernel/sched/fair.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 82 insertions(+), 7 deletions(-)

-- 
2.15.1

             reply	other threads:[~2018-02-13 13:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-13 13:37 Mel Gorman [this message]
2018-02-13 13:37 ` [PATCH 1/6] sched/fair: Avoid an unnecessary lookup of current CPU ID during wake_affine Mel Gorman
2018-02-21 10:27   ` [tip:sched/core] " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 2/6] sched/fair: Defer calculation of prev_eff_load in wake_affine until needed Mel Gorman
2018-02-21 10:28   ` [tip:sched/core] sched/fair: Defer calculation of 'prev_eff_load' in wake_affine_weight() " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 3/6] sched/fair: Do not migrate on wake_affine_weight if weights are equal Mel Gorman
2018-02-21 10:28   ` [tip:sched/core] sched/fair: Do not migrate on wake_affine_weight() " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 4/6] sched/fair: Do not migrate due to a sync wakeup on exit Mel Gorman
2018-02-21 10:29   ` [tip:sched/core] " tip-bot for Peter Zijlstra
2018-02-13 13:37 ` [PATCH 5/6] sched/fair: Consider SD_NUMA when selecting the most idle group to schedule on Mel Gorman
2018-02-21 10:29   ` [tip:sched/core] " tip-bot for Mel Gorman
2018-02-13 13:37 ` [PATCH 6/6] sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine Mel Gorman
2018-02-13 14:01   ` Peter Zijlstra
2018-02-13 14:18     ` Mel Gorman
2018-02-13 14:43       ` Peter Zijlstra
2018-02-13 15:00         ` Mel Gorman
2018-02-13 15:10           ` Peter Zijlstra
2018-02-21 10:30   ` [tip:sched/core] sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine() tip-bot for Mel Gorman
2018-05-07 11:06     ` Srikar Dronamraju
2018-05-09  8:41       ` Mel Gorman
2018-05-09 10:58         ` Srikar Dronamraju
2018-05-09 16:34           ` Mel Gorman

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=20180213133730.24064-1-mgorman@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=efault@gmx.de \
    --cc=ggherdovich@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.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 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.