From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
anton@samba.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, cl@linux.com,
gkurz@linux.vnet.ibm.com, grant.likely@linaro.org,
nikunj@linux.vnet.ibm.com, khandual@linux.vnet.ibm.com
Subject: Re: [PATCH RFC 4/5] powerpc:numa Add helper functions to maintain chipid to nid mapping
Date: Wed, 30 Sep 2015 00:30:43 +0530 [thread overview]
Message-ID: <560ADFDB.6090106@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150928173245.GD48470@linux.vnet.ibm.com>
On 09/28/2015 11:02 PM, Nishanth Aravamudan wrote:
> On 27.09.2015 [23:59:12 +0530], Raghavendra K T wrote:
>> Create arrays that maps serial nids and sparse chipids.
>>
>> Note: My original idea had only two arrays of chipid to nid map. Final
>> code is inspired by driver/acpi/numa.c that maps a proximity node with
>> a logical node by Takayoshi Kochi <t-kochi@bq.jp.nec.com>, and thus
>> uses an additional chipid_map nodemask. The mask helps in first unused
>> nid easily by knowing first unset bit in the mask.
>>
>> No change in functionality.
>>
>> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/mm/numa.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 47 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index dd2073b..f015cad 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -63,6 +63,11 @@ static int form1_affinity;
>> static int distance_ref_points_depth;
>> static const __be32 *distance_ref_points;
>> static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
>> +static nodemask_t chipid_map = NODE_MASK_NONE;
>> +static int chipid_to_nid_map[MAX_NUMNODES]
>> + = { [0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE };
>
> Hrm, conceptually there are *more* chips than nodes, right? So what
> guarantees we won't see > MAX_NUMNODES chips?
You are correct that nid <= chipids.
and #nids = #chipids when all possible slots are populated. Considering
we assume that maximum chip slots are no more than MAX_NUMNODES,
how about having
#define MAX_CHIPNODES MAX_NUMNODES
and
chipid_to_nid_map[MAX_CHIPNODES] = { [0 ... MAX_CHIPNODES - 1] = ..
>
>> +static int nid_to_chipid_map[MAX_NUMNODES]
>> + = { [0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE };
>>
>> /*
>> * Allocate node_to_cpumask_map based on number of available nodes
>> @@ -133,6 +138,48 @@ static int __init fake_numa_create_new_node(unsigned long end_pfn,
>> return 0;
>> }
>>
>> +int chipid_to_nid(int chipid)
>> +{
>> + if (chipid < 0)
>> + return NUMA_NO_NODE;
>
> Do you really want to support these cases? Or should they be
> bugs/warnings indicating that you got an unexpected input? Or at least
> WARN_ON_ONCE?
>
Right. Querying for nid of an invalid chipid should be atleast
WARN_ON_ONCE(). But 'll check once if there is any valid scenario
before the change.
>> + return chipid_to_nid_map[chipid];
>> +}
>> +
>> +int nid_to_chipid(int nid)
>> +{
>> + if (nid < 0)
>> + return NUMA_NO_NODE;
>> + return nid_to_chipid_map[nid];
>> +}
>> +
>> +static void __map_chipid_to_nid(int chipid, int nid)
>> +{
>> + if (chipid_to_nid_map[chipid] == NUMA_NO_NODE
>> + || nid < chipid_to_nid_map[chipid])
>> + chipid_to_nid_map[chipid] = nid;
>> + if (nid_to_chipid_map[nid] == NUMA_NO_NODE
>> + || chipid < nid_to_chipid_map[nid])
>> + nid_to_chipid_map[nid] = chipid;
>> +}
>
> chip <-> node mapping is a static (physical) concept, right? Should we
> emit some debugging if for some reason we get a runtime call to remap
> an already mapped chip to a new node?
>
Good point. Already mapped chipid to a different nid is unexpected
whereas mapping chipid to same nid is expected.(because mapping comes
from cpus belonging to same node).
WARN_ON() should suffice here?
>> +
>> +int map_chipid_to_nid(int chipid)
>> +{
>> + int nid;
>> +
>> + if (chipid < 0 || chipid >= MAX_NUMNODES)
>> + return NUMA_NO_NODE;
>> +
>> + nid = chipid_to_nid_map[chipid];
>> + if (nid == NUMA_NO_NODE) {
>> + if (nodes_weight(chipid_map) >= MAX_NUMNODES)
>> + return NUMA_NO_NODE;
>
> If you create a KVM guest with a bogus topology, doesn't this just start
> losing NUMA information for very high-noded guests?
>
'll try to see if it is possible to hit this case, ideally we should
not allow more than MAX_NUMNODES for chipids and we should abort early.
>> + nid = first_unset_node(chipid_map);
>> + __map_chipid_to_nid(chipid, nid);
>> + node_set(nid, chipid_map);
>> + }
>> + return nid;
>> +}
>> +
>> int numa_cpu_lookup(int cpu)
>> {
>> return numa_cpu_lookup_table[cpu];
>> @@ -264,7 +311,6 @@ out:
>> return chipid;
>> }
>>
>> -
>
> stray change?
>
yep, will correct that.
next prev parent reply other threads:[~2015-09-29 19:00 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-27 18:29 [PATCH RFC 0/5] powerpc:numa Add serial nid support Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 1/5] powerpc:numa Add numa_cpu_lookup function to update lookup table Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-27 18:41 ` Raghavendra K T
2015-10-06 10:17 ` [RFC, " Michael Ellerman
2015-10-06 10:33 ` Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 2/5] powerpc:numa Rename functions referring to nid as chipid Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 17:27 ` Nishanth Aravamudan
2015-09-29 18:31 ` Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 3/5] powerpc:numa create 1:1 mappaing between chipid and nid Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 17:28 ` Nishanth Aravamudan
2015-09-28 17:28 ` Nishanth Aravamudan
2015-09-29 18:35 ` Raghavendra K T
2015-09-29 18:35 ` Raghavendra K T
2015-09-28 17:35 ` Nishanth Aravamudan
2015-09-28 17:35 ` Nishanth Aravamudan
2015-09-29 19:20 ` Raghavendra K T
2015-09-29 19:20 ` Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 4/5] powerpc:numa Add helper functions to maintain chipid to nid mapping Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 17:32 ` Nishanth Aravamudan
2015-09-29 19:00 ` Raghavendra K T [this message]
2015-09-27 18:29 ` [PATCH RFC 5/5] powerpc:numa Use chipid to nid mapping to get serial numa node ids Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 10:44 ` [PATCH RFC 0/5] powerpc:numa Add serial nid support Denis Kirjanov
2015-09-28 17:04 ` Nishanth Aravamudan
2015-09-29 18:20 ` Raghavendra K T
2015-09-29 19:46 ` Denis Kirjanov
2015-09-30 6:16 ` Raghavendra K T
2015-09-28 17:34 ` Nishanth Aravamudan
2015-09-29 19:10 ` Raghavendra K T
2015-10-06 10:25 ` Michael Ellerman
2015-10-06 11:15 ` Raghavendra K T
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=560ADFDB.6090106@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux.com \
--cc=gkurz@linux.vnet.ibm.com \
--cc=grant.likely@linaro.org \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=nacc@linux.vnet.ibm.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulus@samba.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.