On 09/28/2015 10:57 PM, Nishanth Aravamudan wrote:
On 27.09.2015 [23:59:10 +0530], Raghavendra K T wrote:
There is no change in the fuctionality
Signed-off-by: Raghavendra K T <raghavendra...@linux.vnet.ibm.com>
---
arch/powerpc/mm/numa.c | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index d5e6eee..f84ed2f 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -235,47 +235,47 @@ static void initialize_distance_lookup_table(int nid,
}
}
-/* Returns nid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
+/* Returns chipid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
* info is found.
*/
-static int associativity_to_nid(const __be32 *associativity)
+static int associativity_to_chipid(const __be32 *associativity)
This is confusing to me. This function is also used by the DLPAR code
under PowerVM to indicate what node the CPU is on -- not a chip (which I
don't believe is exposed at all under PowerVM).
Good point.
should I retain the name nid?
or any suggestions? instead of chipid -> nid which fits both the cases.
or should I rename like nid->vnid something?
[...]
@@ -1415,7 +1415,7 @@ int arch_update_cpu_topology(void)
/* Use associativity from first thread for all siblings */
vphn_get_associativity(cpu, associativity);
- new_nid = associativity_to_nid(associativity);
+ new_nid = associativity_to_chipid(associativity);
If you are getting a chipid, shouldn't you be assigning it to a variable
called 'new_chipid'?
yes perhaps.
my splitting idea was
1. change nid name in functions to chipid (without changing nid
variable calling that function)
2. rename variables to chipid and assign nid=chipid (1:1 mapping)
3. now let nid = mapped chipid
But I see that it isn't consistent in some places. do you think
merging step 1 and step 2 is okay?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
