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: 26+ 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: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-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-28 17:28 ` Nishanth Aravamudan
2015-09-29 18:35 ` Raghavendra K T
2015-09-28 17:35 ` Nishanth Aravamudan
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-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-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 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).