Re: [PATCH v5 8/9] arm64: topology: Enable ACPI/PPTT based CPU topology.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 12/13/2017 12:22 PM, Lorenzo Pieralisi wrote:
Nit: remove the period in $SUBJECT and capitalize with a coherent
policy for the patches touching the same code.

Ok, thanks.


On Fri, Dec 01, 2017 at 04:23:29PM -0600, Jeremy Linton wrote:
Propagate the topology information from the PPTT tree to the
cpu_topology array. We can get the thread id, core_id and
cluster_id by assuming certain levels of the PPTT tree correspond
to those concepts. The package_id is flagged in the tree and can be
found by calling find_acpi_cpu_topology_package() which terminates
its search when it finds an ACPI node flagged as the physical
package. If the tree doesn't contain enough levels to represent
all of the requested levels then the root node will be returned
for all subsequent levels.

Signed-off-by: Jeremy Linton <jeremy.linton@xxxxxxx>
---
  arch/arm64/kernel/topology.c | 47 +++++++++++++++++++++++++++++++++++++++++++-
  include/linux/topology.h     |  2 ++
  2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 74a8a5173a35..198714aca9e8 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -11,6 +11,7 @@
   * for more details.
   */
+#include <linux/acpi.h>
  #include <linux/arch_topology.h>
  #include <linux/cpu.h>
  #include <linux/cpumask.h>
@@ -22,6 +23,7 @@
  #include <linux/sched.h>
  #include <linux/sched/topology.h>
  #include <linux/slab.h>
+#include <linux/smp.h>
  #include <linux/string.h>
#include <asm/cpu.h>
@@ -300,6 +302,47 @@ static void __init reset_cpu_topology(void)
  	}
  }
+#ifdef CONFIG_ACPI
+/*
+ * Propagate the topology information of the processor_topology_node tree to the
+ * cpu_topology array.
+ */
+static int __init parse_acpi_topology(void)
+{
+	u64 is_threaded;

Nit: a bool would be preferable.

+	int cpu;
+	int topology_id;

int cpu, topology_id;

+	is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;

+	for_each_possible_cpu(cpu) {
+		topology_id = find_acpi_cpu_topology(cpu, 0);
+		if (topology_id < 0)
+			return topology_id;
+
+		if (is_threaded) {
+			cpu_topology[cpu].thread_id = topology_id;
+			topology_id = find_acpi_cpu_topology(cpu, 1);
+			cpu_topology[cpu].core_id   = topology_id;
+			topology_id = find_acpi_cpu_topology_package(cpu);
+			cpu_topology[cpu].physical_id = topology_id;
+		} else {
+			cpu_topology[cpu].thread_id  = -1;
+			cpu_topology[cpu].core_id    = topology_id;
+			topology_id = find_acpi_cpu_topology_package(cpu);
+			cpu_topology[cpu].physical_id = topology_id;
+		}
+	}

Add a space.

It is probably my fault so apologies if that's the case. The

find_acpi_cpu_topology()

API is a bit strange since it behaves differently according to the
level passed in.

? In the sense that the id is more directly defined by the firmware for level0? Not sure this really matters, particularly if at some future point we come up with a way to standardize an id for the sockets/etc (or we just renumber the nodes).

AKA, I don't see a problem as we aren't making any guarantees about what the return id represents other than its unique for siblings at a given level.


I think it is better to define two calls (it might well have been like
that in one of the previous series versions):

- find_acpi_cpu_package_level() (returns: package level if success, <0 on
   failure)
- acpi_cpu_topology_id()

So, knowing the absolute level a given flag is set at allows you to query a node relative to that level. That is a good idea if you wanted to identify say a numa in package level (say package-1). But its complicated by that fact that package-1 may be meaningless in a lot of cases (maybe package-1 is just a core). The alternative here for finding a numa proximity domain is to try to find a PPTT node with a subset of cores which happens to match an proximity domain. But given there is currently nothing in the specification which requires a 1:1 mapping between a given set of PPTT nodes and a proximity domain (given the PPTT is focused on cache nodes) I tend to think we want further flags in the PPTT and language that makes it clear when this happens. So the interface should be more generic find_acpi_cpu_flag_level(cpu, flag). That way we avoid the complexity of trying to guess from a relative level if a particular topological feature is appropriate.



It would even be better to lump the two calls together but you do not
know how many topology levels are there so it becomes a bit complicated
to handle.

Right, which is basically what the underlying find_acpi_cpu_topology_tag() is doing at the moment. My tendency here is just to export that call and let the PPTT parsing code wrap the decision about what to do if the flag can't be found. Which means the whole discussion above about letting the higher level code try to infer relative levels is a last resort. I'm more for creating a couple additional flags (FLAG_GIVE_ME_LEVEL_WHERE_NUMA_STARTS) and feeding it to acpi_cpu_topology_tag() with some additional logic which says something to the affect, return the NUMA level in the PPTT described by some future standardized flag, otherwise return the socket level, and if that doesn't exist return the root node level (or maybe if we get desperate a node which seems to match a SRAT proximity domain). That keeps the PPTT interface fairly simple, and keeps the level selection out of the common topology code.


There are also some other possible future directions which don't fit any of these models. So in that regard I think we want to keep the inteface as simple as possible, and transform it in the future when we have a direct need for it.
	
Thanks,


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux