From: Sudeep Holla <sudeep.holla@arm.com> To: Andrew Jones <drjones@redhat.com> Cc: Jeremy Linton <jeremy.linton@arm.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ard.biesheuvel@linaro.org, shunyong.yang@hxt-semitech.com, yu.zheng@hxt-semitech.com, catalin.marinas@arm.com, will.deacon@arm.com Subject: Re: [PATCH] arm64: acpi: reenumerate topology ids Date: Fri, 29 Jun 2018 14:38:49 +0100 [thread overview] Message-ID: <20180629133849.GB16282@e107155-lin> (raw) In-Reply-To: <20180629114227.4noje2kx3lcjbcpd@kamzik.brq.redhat.com> On Fri, Jun 29, 2018 at 01:42:27PM +0200, Andrew Jones wrote: > On Fri, Jun 29, 2018 at 11:53:34AM +0100, Sudeep Holla wrote: > > On Thu, Jun 28, 2018 at 12:12:00PM -0500, Jeremy Linton wrote: > > > Hi, > > > > > > On 06/28/2018 11:30 AM, Sudeep Holla wrote: > > > > [...] > > > > > >I am not sure if we can ever guarantee that DT and ACPI will get the > > > >same ids whatever counter we use as it depends on the order presented in > > > >the firmware(DT or ACPI). So I am not for generating ids for core and > > > >threads in that way. > > > > > > > >So I would like to keep it simple and just have this counters for > > > >package ids as demonstrated in Shunyong's patch. > > > > > > So, currently on a non threaded system, the core id's look nice because they > > > are just the ACPI ids. Its the package id's that look strange, we could just > > > fix the package ids, but on threaded machines the threads have the nice acpi > > > ids, and the core ids are then funny numbers. So, I suspect that is driving > > > this as much as the strange package ids. > > > > > > > Yes, I know that and that's what made be look at topology_get_acpi_cpu_tag > > For me, if the PPTT has valid ID, we should use that. Just becuase DT lacks > > it and uses counter doesn't mean ACPI also needs to follow that. > > AFAIK, a valid ACPI UID doesn't need to be something derivable directly > from the hardware, so it's just as arbitrary as the CPU phandle that is > in the DT cpu-map, i.e. DT *does* have an analogous leaf node integer. > Its platform specific, left to vendors to identify that. Are you referring to reg property in DT for leaf nodes ? If so, that's MPIDR and is present in ACPI MADT. > > > > I am sure some vendor will put valid UID and expect that to be in the > > sysfs. > > I can't think of any reason that would be useful, especially when the > UID is for a thread, which isn't even displayed by sysfs. > You are mixing MPIDR and UID here. > > > > > (and as a side, I actually like the PE has a acpi id behavior, but for > > > threads its being lost with this patch...) > > > > > > Given i've seen odd package/core ids on x86s a few years ago, it never > > So this inspired me to grep some x86 topology code. I found > arch/x86/kernel/smpboot.c:topology_update_package_map(), which uses > a counter to set the logical package id and Documentation/x86/topology.txt > states > > """ > - cpuinfo_x86.logical_id: > > The logical ID of the package. As we do not trust BIOSes to enumerate the > packages in a consistent way, we introduced the concept of logical package > ID so we can sanely calculate the number of maximum possible packages in > the system and have the packages enumerated linearly. > """ > > Which I see as x86 precedent for the consistency argument I made in my > other reply. > There are lots of things arm64 doesn't replicate x86. So I don't take that as valid argument. It's a new feature, we can use APCI PPTT UID feature to be consistent. I don't see counter being in anyway consistent. Even PPTT could be generated in the firmware and the order is not consistent. In which case the counter values in Linux might get things wrong while using UID from the firmware can keep it consistent(e.g. sockets removed,..etc) -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] arm64: acpi: reenumerate topology ids Date: Fri, 29 Jun 2018 14:38:49 +0100 [thread overview] Message-ID: <20180629133849.GB16282@e107155-lin> (raw) In-Reply-To: <20180629114227.4noje2kx3lcjbcpd@kamzik.brq.redhat.com> On Fri, Jun 29, 2018 at 01:42:27PM +0200, Andrew Jones wrote: > On Fri, Jun 29, 2018 at 11:53:34AM +0100, Sudeep Holla wrote: > > On Thu, Jun 28, 2018 at 12:12:00PM -0500, Jeremy Linton wrote: > > > Hi, > > > > > > On 06/28/2018 11:30 AM, Sudeep Holla wrote: > > > > [...] > > > > > >I am not sure if we can ever guarantee that DT and ACPI will get the > > > >same ids whatever counter we use as it depends on the order presented in > > > >the firmware(DT or ACPI). So I am not for generating ids for core and > > > >threads in that way. > > > > > > > >So I would like to keep it simple and just have this counters for > > > >package ids as demonstrated in Shunyong's patch. > > > > > > So, currently on a non threaded system, the core id's look nice because they > > > are just the ACPI ids. Its the package id's that look strange, we could just > > > fix the package ids, but on threaded machines the threads have the nice acpi > > > ids, and the core ids are then funny numbers. So, I suspect that is driving > > > this as much as the strange package ids. > > > > > > > Yes, I know that and that's what made be look at topology_get_acpi_cpu_tag > > For me, if the PPTT has valid ID, we should use that. Just becuase DT lacks > > it and uses counter doesn't mean ACPI also needs to follow that. > > AFAIK, a valid ACPI UID doesn't need to be something derivable directly > from the hardware, so it's just as arbitrary as the CPU phandle that is > in the DT cpu-map, i.e. DT *does* have an analogous leaf node integer. > Its platform specific, left to vendors to identify that. Are you referring to reg property in DT for leaf nodes ? If so, that's MPIDR and is present in ACPI MADT. > > > > I am sure some vendor will put valid UID and expect that to be in the > > sysfs. > > I can't think of any reason that would be useful, especially when the > UID is for a thread, which isn't even displayed by sysfs. > You are mixing MPIDR and UID here. > > > > > (and as a side, I actually like the PE has a acpi id behavior, but for > > > threads its being lost with this patch...) > > > > > > Given i've seen odd package/core ids on x86s a few years ago, it never > > So this inspired me to grep some x86 topology code. I found > arch/x86/kernel/smpboot.c:topology_update_package_map(), which uses > a counter to set the logical package id and Documentation/x86/topology.txt > states > > """ > - cpuinfo_x86.logical_id: > > The logical ID of the package. As we do not trust BIOSes to enumerate the > packages in a consistent way, we introduced the concept of logical package > ID so we can sanely calculate the number of maximum possible packages in > the system and have the packages enumerated linearly. > """ > > Which I see as x86 precedent for the consistency argument I made in my > other reply. > There are lots of things arm64 doesn't replicate x86. So I don't take that as valid argument. It's a new feature, we can use APCI PPTT UID feature to be consistent. I don't see counter being in anyway consistent. Even PPTT could be generated in the firmware and the order is not consistent. In which case the counter values in Linux might get things wrong while using UID from the firmware can keep it consistent(e.g. sockets removed,..etc) -- Regards, Sudeep
next prev parent reply other threads:[~2018-06-29 13:38 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-28 14:51 [PATCH] arm64: acpi: reenumerate topology ids Andrew Jones 2018-06-28 14:51 ` Andrew Jones 2018-06-28 16:30 ` Sudeep Holla 2018-06-28 16:30 ` Sudeep Holla 2018-06-28 17:12 ` Jeremy Linton 2018-06-28 17:12 ` Jeremy Linton 2018-06-29 10:53 ` Sudeep Holla 2018-06-29 10:53 ` Sudeep Holla 2018-06-29 11:42 ` Andrew Jones 2018-06-29 11:42 ` Andrew Jones 2018-06-29 11:55 ` Andrew Jones 2018-06-29 11:55 ` Andrew Jones 2018-06-29 13:48 ` Sudeep Holla 2018-06-29 13:48 ` Sudeep Holla 2018-06-29 13:38 ` Sudeep Holla [this message] 2018-06-29 13:38 ` Sudeep Holla 2018-06-29 16:03 ` Andrew Jones 2018-06-29 16:03 ` Andrew Jones 2018-06-28 17:32 ` Andrew Jones 2018-06-28 17:32 ` Andrew Jones 2018-06-29 10:29 ` Sudeep Holla 2018-06-29 10:29 ` Sudeep Holla 2018-06-29 11:23 ` Andrew Jones 2018-06-29 11:23 ` Andrew Jones 2018-06-29 13:29 ` Sudeep Holla 2018-06-29 13:29 ` Sudeep Holla 2018-06-29 15:46 ` Andrew Jones 2018-06-29 15:46 ` Andrew Jones 2018-06-29 15:55 ` Sudeep Holla 2018-06-29 15:55 ` Sudeep Holla 2018-06-29 16:48 ` Jeremy Linton 2018-06-29 16:48 ` Jeremy Linton 2018-06-29 17:03 ` Andrew Jones 2018-06-29 17:03 ` Andrew Jones 2018-06-29 17:23 ` Sudeep Holla 2018-06-29 17:23 ` Sudeep Holla 2018-06-29 18:03 ` Andrew Jones 2018-06-29 18:03 ` Andrew Jones 2018-07-02 14:58 ` Jeffrey Hugo 2018-07-02 14:58 ` Jeffrey Hugo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180629133849.GB16282@e107155-lin \ --to=sudeep.holla@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=drjones@redhat.com \ --cc=jeremy.linton@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=shunyong.yang@hxt-semitech.com \ --cc=will.deacon@arm.com \ --cc=yu.zheng@hxt-semitech.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.