Hi Jeffrey, On 05/10/2018 17:39, Jeffrey Hugo wrote: > On 10/5/2018 9:54 AM, James Morse wrote: >> The problem is generating these numbers if only some of the CPUs are online, or >> if the acpi tables are generated by firmware at power-on and have a different >> layout every time. >> We don't even want to rely on linux's cpu numbering. >> >> The suggestion here is to use the smallest MPIDR, as that's as hardware property >> that won't change even if the tables are generated differently every boot. > > I can't think of a reason why affinity level 0 would ever change for a affinity level of what? The caches? Sure, that should be impossible to change. > particular thread or core (SMT vs non-SMT), however none of the other affinity > levels have a well defined meaning (implementation dependent), and could very > well change boot to boot. Ah, you mean the level numbers. Yes, these are (quasi) discovered from the table, so can't be relied on. If you insert a new level then this would shuffle the user-visible indexes and levels. I would argue this is no longer the same hardware. Doing this may already break resctrl as the 'L2' and 'L3' numbers are part of the ABI. The ids generated would still be unique for a level. > I would strongly avoid using MPIDR, particularly for the usecase you've described. Is there an alternative? It needs to be a hardware property to insulate us from the tables being re-generated. I agree the MPIDR numbers are likely to be ugly, (I don't really care...). The u32 id being full from day 1 is more of a problem. >> Assuming two clusters in your example above, it would look like: >> >> | CPU0/1 (cluster 0) L2 - 0x0 >> | CPU2/3 (cluster 1) L2 - 0x100 >> | L3 - 0x0 > > Thanks for the clarification. I think I've got enough to wrap my head around > this. Let me think on it a bit to see if I can come up with a suggestion (we > can debate how good it is). Sounds good. Thanks! James
