On 28/06/18 12:57, Andrew Jones wrote:
On Thu, Jun 28, 2018 at 10:38:24AM +0100, Sudeep Holla wrote:
Hi Shunyong,
On 28/06/18 10:18, Shunyong Yang wrote:
As PPTT spec doesn't define the physical package id,
find_acpi_cpu_topology_package() will return offset of the node with
Physical package field set when querying physical package id. So, it
returns 162(0xA2) in following example.
[0A2h 0162 1] Subtable Type : 00 [Processor Hierarchy
Node]
[0A3h 0163 1] Length : 1C
[0A4h 0164 2] Reserved : 0000
[0A6h 0166 4] Flags (decoded below) : 00000003
Physical package : 1
ACPI Processor ID valid : 1
[0AAh 0170 4] Parent : 00000000
[0AEh 0174 4] ACPI Processor ID : 00001000
[0B2h 0178 4] Private Resource Number : 00000002
[0B6h 0182 4] Private Resource : 0000006C
[0BAh 0186 4] Private Resource : 00000084
So, when "cat physical_package" in /sys/devices/system/cpu/cpu0/topology/,
it will output 162(0xA2). And if some items are added before the node
above, the output will change to other value.
This patch maps the node offset to a logic package id. It maps the first
node offset to 0, the second to 1, and so on.
Then, it will not output a big value, such as 162 above. And it will
not change when some nodes(Physical package not set) are added.
And as long as the nodes with Physical package field set in PPTT keeps
the real hardware order, the logic id can map to hardware package id to
some extent.
Hope to get feedback from you.
Thanks for the patch, but Andrew Jones has also posted a patch[1] which
I had a look but was not sure what is the best approach to fix it yet.
I will think about it and respond to that.
I'll send a v1 yet today. The RFC version was actually OK, as the concern
with ACPI nodes not being in the expected order wasn't actually a problem.
The thread-id or core-id would only be reset to zero when a yet to be
remapped core-id (and all its peers) was found when iterating the PEs.
Since all peers were handled at the same time, the counter reset was
correct, even when the ACPI nodes were out-of-order. The code didn't make
that very obvious, though, and there was some room for other cleanups,
so I've reworked it. Once I run it through a couple more rounds of testing
I'll repost.
OK sure. I liked the approach in Shunyong's patch. I was thinking if we
can avoid the list and dynamic allocation on each addition and make it
more simpler.