From: Khalid Aziz <khalid.aziz@oracle.com>
To: sparclinux@vger.kernel.org
Subject: Re: [PATCH v2] sparc64: Fix numa node distance initialization
Date: Fri, 08 Jan 2016 01:24:35 +0000 [thread overview]
Message-ID: <568F0FD3.6050902@oracle.com> (raw)
In-Reply-To: <1452062135-58381-1-git-send-email-nitin.m.gupta@oracle.com>
On 01/05/2016 11:35 PM, Nitin Gupta wrote:
> Orabug: 22495713
>
> Currently, NUMA node distance matrix is initialized only
> when a machine descriptor (MD) exists. However, sun4u
> machines (e.g. Sun Blade 2500) do not have an MD and thus
> distance values were left uninitialized. The initialization
> is now moved such that it happens on both sun4u and sun4v.
>
> Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>
> Tested-by: Mikael Pettersson <mikpelinux@gmail.com>
> ---
> arch/sparc/mm/init_64.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> Changelog v1 vs v2:
> - Move numa distance values initialization outside
> of numa_enabled conditional (Khalid)
> - Add an empty line between variable declaration
> and other code (David)
>
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 3025bd5..6f21685 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -1267,13 +1267,6 @@ static int __init numa_parse_mdesc(void)
> int i, j, err, count;
> u64 node;
>
> - /* Some sane defaults for numa latency values */
> - for (i = 0; i < MAX_NUMNODES; i++) {
> - for (j = 0; j < MAX_NUMNODES; j++)
> - numa_latency[i][j] = (i = j) ?
> - LOCAL_DISTANCE : REMOTE_DISTANCE;
> - }
> -
> node = mdesc_node_by_name(md, MDESC_NODE_NULL, "latency-groups");
> if (node = MDESC_NODE_NULL) {
> mdesc_release(md);
> @@ -1369,10 +1362,18 @@ static int __init numa_parse_sun4u(void)
>
> static int __init bootmem_init_numa(void)
> {
> + int i, j;
> int err = -1;
>
> numadbg("bootmem_init_numa()\n");
>
> + /* Some sane defaults for numa latency values */
> + for (i = 0; i < MAX_NUMNODES; i++) {
> + for (j = 0; j < MAX_NUMNODES; j++)
> + numa_latency[i][j] = (i = j) ?
> + LOCAL_DISTANCE : REMOTE_DISTANCE;
> + }
> +
> if (numa_enabled) {
> if (tlb_type = hypervisor)
> err = numa_parse_mdesc();
>
Hi Nitin,
I don't mean to be nitpicking, just want to make sure "numa=off"
behavior gets handled correctly. With this code change, node_distance()
will return either LOCAL_DISTANCE or REMOTE_DISTANCE even when kernel is
booted up with "numa=off". Would that end up not honoring "numa=off"?
Should this loop initialize all numa_latency elements to LOCAL_DISTANCE
if numa_enabled is not true, otherwise to LOCAL_DISTANCE and
REMOTE_DISTANCE as appropriate? Please do let me know if it really is
not a concern here.
Thanks,
Khalid
next prev parent reply other threads:[~2016-01-08 1:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 6:35 [PATCH v2] sparc64: Fix numa node distance initialization Nitin Gupta
2016-01-08 1:24 ` Khalid Aziz [this message]
2016-01-14 21:22 ` David Miller
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=568F0FD3.6050902@oracle.com \
--to=khalid.aziz@oracle.com \
--cc=sparclinux@vger.kernel.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