On Fri, Jun 29, 2018 at 02:29:34PM +0100, Sudeep Holla wrote: > If it matters a lot, vendors must use UID for consistency. Since OS doesn't > use those IDs for any particular reason, OS must not care.
That depends. If you look at how topology_logical_package_id() is used in x86 code you'll see it gets used as an index to an array in a couple places. If we don't remap arbitrary IDs to counters than we may miss out on some opportunities to avoid lists. Also, we're talking about what's visible to users. I think it's much more likely to break a user app by exposing topology IDs that have values greater than the linear CPU numbers (even though properly written apps shouldn't expect them to be strictly <=), than the opposite. > > > > > > > > > > > > > > So I would like to keep it simple and just have this counters for > > > > > package ids as demonstrated in Shunyong's patch. > > > > > > > > > > > > > If we don't also handle cores when there are threads, then the cores > > > > will also end up having weird IDs. > > > > > > > > > > Yes, but if PPTT says it has valid ID, I would prefer that over DT like > > > generated. > > > > Valid *ACPI* ID, which just means it's a guaranteed unique ACPI UID, > > which isn't likely going to be anything useful to a user. > > > > How is that different from OS generated one from user's perspective ? > Vendors might assign sockets UID and he may help them to replace one. > Having some generated counter based id is not helpful. I agree with this. It's a good argument for maintaining a mapping of package-id to id-physically-printed-on-a-package somewhere. To avoid maintaining a mapping it could just be stored directly in cpu_topology[cpu].package_id, but then how can we tell the difference between a valid printed-on-package-id and an ACPI offset? We'd still have to maintain additional state to determine if it's valid or not, so we could just maintain a mapping instead. Thanks, drew
