From: Paul Mackerras <paulus@samba.org>
To: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 7/11] Use stop machine to update cpu maps
Date: Thu, 4 Apr 2013 15:46:54 +1100 [thread overview]
Message-ID: <20130404044654.GH19443@drongo> (raw)
In-Reply-To: <51509E3C.2030008@linux.vnet.ibm.com>
On Mon, Mar 25, 2013 at 01:58:04PM -0500, Nathan Fontenot wrote:
> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>
> The new PRRN firmware feature allows CPU and memory resources to be
> transparently reassigned across NUMA boundaries. When this happens, the
> kernel must update the node maps to reflect the new affinity
> information.
>
> Although the NUMA maps can be protected by locking primitives during the
> update itself, this is insufficient to prevent concurrent accesses to these
> structures. Since cpumask_of_node() hands out a pointer to these
> structures, they can still be modified outside of the lock. Furthermore,
> tracking down each usage of these pointers and adding locks would be quite
> invasive and difficult to maintain.
>
> Situations like these are best handled using stop_machine(). Since the NUMA
> affinity updates are exceptionally rare events, this approach has the
> benefit of not adding any overhead while accessing the NUMA maps during
> normal operation.
I notice you do one stop_machine() call for every cpu whose affinity
has changed. Couldn't we update the affinity for them all in one
stop_machine call? Given that stopping the whole machine can be quite
slow, wouldn't it be better to do one call rather than potentially
many?
Paul.
next prev parent reply other threads:[~2013-04-04 4:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 18:43 [PATCH v2 0/11] NUMA CPU Reconfiguration using PRRN Nathan Fontenot
2013-03-25 18:51 ` [PATCH v2 1/11] Expose pseries devicetree_update() Nathan Fontenot
2013-04-04 3:09 ` Paul Mackerras
2013-03-25 18:52 ` [PATCH v2 2/11] Add PRRN Event Handler Nathan Fontenot
2013-04-04 3:34 ` Paul Mackerras
2013-04-04 7:16 ` Benjamin Herrenschmidt
2013-04-05 15:43 ` Nathan Fontenot
2013-04-10 8:30 ` Michael Ellerman
2013-04-15 20:12 ` Nathan Fontenot
2013-03-25 18:53 ` [PATCH v2 3/11] Move architecture vector definitions to prom.h Nathan Fontenot
2013-03-25 18:54 ` [PATCH v2 4/11] Update firmware_has_feature() to check architecture bits Nathan Fontenot
2013-04-04 4:19 ` Paul Mackerras
2013-03-25 18:56 ` [PATCH v2 5/11] Update numa.c to use updated firmware_has_feature() Nathan Fontenot
2013-04-04 4:20 ` Paul Mackerras
2013-03-25 18:57 ` [PATCH v2 6/11] Update CPU Maps Nathan Fontenot
2013-04-04 4:42 ` Paul Mackerras
2013-04-05 18:02 ` Nathan Fontenot
2013-03-25 18:58 ` [PATCH v2 7/11] Use stop machine to update cpu maps Nathan Fontenot
2013-04-04 4:46 ` Paul Mackerras [this message]
2013-04-05 18:22 ` Nathan Fontenot
2013-04-23 0:23 ` Benjamin Herrenschmidt
2013-03-25 18:59 ` [PATCH v2 8/11] Update numa cpu vdso info Nathan Fontenot
2013-03-25 19:00 ` [PATCH v2 9/11] Re-enable Virtual Private Home Node capabilities Nathan Fontenot
2013-03-25 19:01 ` [PATCH v2 10/11] Enable PRRN Nathan Fontenot
2013-03-25 19:02 ` [PATCH v2 11/11] Add /proc interface to control topology updates Nathan Fontenot
2013-04-10 6:59 ` Michael Ellerman
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=20130404044654.GH19443@drongo \
--to=paulus@samba.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nfont@linux.vnet.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).