On 20/10/17 17:14, Jeremy Linton wrote: > Hi, > > On 10/20/2017 04:14 AM, Lorenzo Pieralisi wrote: >> On Thu, Oct 19, 2017 at 11:13:27AM -0500, Jeremy Linton wrote: >>> On 10/19/2017 10:56 AM, Lorenzo Pieralisi wrote: >>>> On Thu, Oct 12, 2017 at 02:48:55PM -0500, 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 passing an arbitrary large level to setup_acpi_cpu_topology() >>>>> 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 thread/core/cod/package then the package >>>>> id will be used for the missing levels. >>>>> >>>>> Since server/ACPI machines are more likely to be multisocket and NUMA, >>>> >>>> I think this stuff is vague enough already so to start with I would >>>> drop >>>> patch 4 and 5 and stop assuming what machines are more likely to ship >>>> with ACPI than DT. >>>> >>>> I am just saying, for the umpteenth time, that these levels have no >>>> architectural meaning _whatsoever_, level is a hierarchy concept >>>> with no architectural meaning attached. >>> >>> ? >>> >>> Did anyone say anything about that? No, I think the only thing being >>> guaranteed here is that the kernel's physical_id maps to an ACPI >>> defined socket. Which seems to be the mindset of pretty much the >>> entire !arm64 community meaning they are optimizing their software >>> and the kernel with that concept in mind. >>> >>> Are you denying the existence of non-uniformity between threads >>> running on different physical sockets? >> >> No, I have not explained my POV clearly, apologies. >> >> AFAIK, the kernel currently deals with 2 (3 - if SMT) topology layers. >> >> 1) thread >> 2) core >> 3) package >> >> What I wanted to say is, that, to simplify this series, you do not need >> to introduce the COD topology level, since it is just another arbitrary >> topology level (ie there is no way you can pinpoint which level >> corresponds to COD with PPTT - or DT for the sake of this discussion) >> that would not be used in the kernel (apart from big.LITTLE cpufreq >> driver and PSCI checker whose usage of topology_physical_package_id() is >> questionable anyway). Just thinking out loud here. 1. psci_checker.c : it's just used to get groups of cpu's to achieve deeper idle states. It should be easy to get rid of that. 2. big.LITTLE cpufreq : 2 users, scpi I should be able to do what I did for SCMI and for spc I am thinking if we can hard code it's just used on TC2 -- Regards, Sudeep -- 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
