linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Lynch <nathanl@linux.ibm.com>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: srikar.dronamraju@in.ibm.com, mmc@linux.ibm.com,
	linuxppc-dev@lists.ozlabs.org, mwb@linux.ibm.com,
	julietk@linux.ibm.com
Subject: Re: [PATCH 0/2] disable NUMA affinity reassignments at runtime
Date: Thu, 18 Apr 2019 17:37:31 -0500	[thread overview]
Message-ID: <87imvbrlck.fsf@linux.ibm.com> (raw)
In-Reply-To: <20190418223045.55af6509@naga>

Michal Suchánek <msuchanek@suse.de> writes:

> On Thu, 18 Apr 2019 13:56:56 -0500
> Nathan Lynch <nathanl@linux.ibm.com> wrote:
>
> Hello,
>
>> Changing cpu <-> node relationships at runtime, as the pseries
>> platform code attempts to do for LPM, PRRN, and VPHN is essentially
>> unsupported by core subsystems. [1]
>
> Wasn't there a patch that solves the discrepancy by removing and
> re-adding the updated CPUs?
>
> http://patchwork.ozlabs.org/patch/1051761/

In our testing it seems that changing the result of cpu_to_node() for a
given cpu id, even with an intervening offline/online, leads to crashes
and assertions in the slab allocator. There have been some ideas floated
to sidestep that but I think there are larger issues to consider.

Even if changing CPU node assignments were possible to do without
destabilizing the system it's not all that useful without updating
memory/LMB affinity as well. (VPHN is an exception.)

Furthermore I'm not aware of any effort to make the numa/affinity APIs
at the system call level account for the possibility that the cpu/mem
<-> node relationship could be dynamic. Nor is there any facility for
notifying applications of changes. Even if the kernel were to properly
support this internally, NUMA-aware applications are the ones that will
suffer unless appropriate APIs are provided to them.

To me it seems this all needs more careful consideration and work, and
much of it should happen outside of this particular arch/platform
context.


      reply	other threads:[~2019-04-18 22:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 18:56 [PATCH 0/2] disable NUMA affinity reassignments at runtime Nathan Lynch
2019-04-18 18:56 ` [PATCH 1/2] powerpc/numa: improve control of topology updates Nathan Lynch
2019-04-21 14:19   ` [1/2] " Michael Ellerman
2019-04-18 18:56 ` [PATCH 2/2] powerpc/numa: document topology_updates_enabled, disable by default Nathan Lynch
2019-04-18 20:30 ` [PATCH 0/2] disable NUMA affinity reassignments at runtime Michal Suchánek
2019-04-18 22:37   ` Nathan Lynch [this message]

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=87imvbrlck.fsf@linux.ibm.com \
    --to=nathanl@linux.ibm.com \
    --cc=julietk@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mmc@linux.ibm.com \
    --cc=msuchanek@suse.de \
    --cc=mwb@linux.ibm.com \
    --cc=srikar.dronamraju@in.ibm.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).