From: Andrew Jones <drjones@redhat.com> To: Sudeep Holla <sudeep.holla@arm.com> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, jeremy.linton@arm.com, 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 17:46:08 +0200 [thread overview] Message-ID: <20180629154608.nqudibf54ti6dpjc@kamzik.brq.redhat.com> (raw) In-Reply-To: <20180629132934.GA16282@e107155-lin> 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
WARNING: multiple messages have this Message-ID (diff)
From: drjones@redhat.com (Andrew Jones) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] arm64: acpi: reenumerate topology ids Date: Fri, 29 Jun 2018 17:46:08 +0200 [thread overview] Message-ID: <20180629154608.nqudibf54ti6dpjc@kamzik.brq.redhat.com> (raw) In-Reply-To: <20180629132934.GA16282@e107155-lin> 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
next prev parent reply other threads:[~2018-06-29 15:46 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 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 [this message] 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=20180629154608.nqudibf54ti6dpjc@kamzik.brq.redhat.com \ --to=drjones@redhat.com \ --cc=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.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=sudeep.holla@arm.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.