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 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.