Re: [PATCH RFC 2/3] arch_topology: Parse die nodes in /cpu-map

[Yicong Yang]

On 9/22/26 4:06 PM, Troy Mitchell wrote:
>> Where is the associated bindings ? Am I missing to check it in the series
>> or it is really missing ? It is essential to add any code using the binding.
> 
> I left the binding out to get initial feedback on the topology model,
> but I agree it should be available for review alongside the code.
> 
> The cpu-map binding lives in dt-schema. I have now opened a draft PR [1]
> with the proposed dieN hierarchy. The PR also links back to this kernel
> series.
> 
>> Also how does it align with ACPI implementation ? It is preferred to be
>> in parity here, so we need some binding there as well IMHO.
> 
> This series does not implement ACPI die discovery and leaves die_id at
> -1 on that path. I agree that DT and ACPI should describe the same
> topology model.
> 
> RISC-V does not define topology fields in hart IDs. PPTT can describe
> intermediate processor hierarchy nodes, but I could not find an explicit
> die indicator in the ACPI 6.6 processor-node flags. Is there an existing
> PPTT convention for identifying die boundaries that we should follow?
> 

PPTT describes the hierarchical processor information but except physical
package and SMT, there's no flags to bind the nodes to a real topology
structure. so maybe it's hard to choose one unless a new flag is added by
the spec to indicate the DIE topology.

may I know the target use case for this die information (as I see the same
question raised on the thread of the device tree PR)? IIUC the NUMA and
cluster information should be enough for the software to aware the
performance differences and the scheduler has already make use them.

thanks.

> Would it be acceptable to add DT support first, keeping ACPI die IDs
> unknown until that mapping is agreed, or should the ACPI mapping be
> defined as part of this RFC?
> 
> Link: https://github.com/devicetree-org/dt-schema/pull/208 [1].