From: Robin Murphy <robin.murphy@arm.com>
To: Rob Herring <robh@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
James Morse <james.morse@arm.com>,
Jeremy Linton <jeremy.linton@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
devicetree@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH 2/6] cacheinfo: Set cache 'id' based on DT data
Date: Fri, 17 Dec 2021 16:57:07 +0000 [thread overview]
Message-ID: <881f056d-d1ed-c6de-c09d-6e84d8b14530@arm.com> (raw)
In-Reply-To: <20211216233125.1130793-3-robh@kernel.org>
Hi Rob,
On 2021-12-16 23:31, Rob Herring wrote:
> Use the minimum CPU h/w id of the CPUs associated with the cache for the
> cache 'id'. This will provide a stable id value for a given system. As
> we need to check all possible CPUs, we can't use the shared_cpu_map
> which is just online CPUs. There's not a cache to CPUs mapping in DT, so
> we have to walk all CPU nodes and then walk cache levels.
I believe another expected use of the cache ID exposed in sysfs is to
program steering tags for cache stashing (typically in VFIO-based
userspace drivers like DPDK so we can't realistically mediate it any
other way). There were plans afoot last year to ensure that ACPI PPTT
could provide the necessary ID values for arm64 systems which will
typically be fairly arbitrary (but unique) due to reflecting underlying
interconnect routing IDs. Assuming that there will eventually be some
interest in cache stashing on DT-based systems too, we probably want to
allow for an explicit ID property on DT cache nodes in a similar manner.
That said, I think it does make sense to have some kind of
auto-generated fallback scheme *as well*, since I'm sure there will be
plenty systems which care about MPAM but don't support stashing, and
therefore wouldn't have a meaningful set of IDs to populate their DT
with. Conversely I think that might also matter for ACPI too - one point
I remember from previous discussions is that PPTT may use a compact
representation where a single entry represents all equivalent caches at
that level, so I'm not sure we can necessarily rely on IDs out of that
path being unique either.
Robin.
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> - Loop with for_each_possible_cpu instead of for_each_of_cpu_node as
> we will need the logical cpu numbers.
> ---
> drivers/base/cacheinfo.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 66d10bdb863b..21accddf8f5f 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -136,6 +136,36 @@ static bool cache_node_is_unified(struct cacheinfo *this_leaf,
> return of_property_read_bool(np, "cache-unified");
> }
>
> +static void cache_of_set_id(struct cacheinfo *this_leaf, struct device_node *np)
> +{
> + int cpu;
> + unsigned long min_id = ~0UL;
> +
> + for_each_possible_cpu(cpu) {
> + u64 id;
> + struct device_node *cache_node, *cpu_node;
> +
> + cache_node = cpu_node = of_get_cpu_node(cpu, NULL);
> + id = of_get_cpu_hwid(cpu_node, 0);
> + while ((cache_node = of_find_next_cache_node(cache_node))) {
> + if (cache_node == np) {
> + if (id < min_id) {
> + min_id = id;
> + of_node_put(cache_node);
> + break;
> + }
> + }
> + of_node_put(cache_node);
> + }
> + of_node_put(cpu_node);
> + }
> +
> + if (min_id != ~0UL) {
> + this_leaf->id = min_id;
> + this_leaf->attributes |= CACHE_ID;
> + }
> +}
> +
> static void cache_of_set_props(struct cacheinfo *this_leaf,
> struct device_node *np)
> {
> @@ -151,6 +181,7 @@ static void cache_of_set_props(struct cacheinfo *this_leaf,
> cache_get_line_size(this_leaf, np);
> cache_nr_sets(this_leaf, np);
> cache_associativity(this_leaf);
> + cache_of_set_id(this_leaf, np);
> }
>
> static int cache_setup_of_node(unsigned int cpu)
next prev parent reply other threads:[~2021-12-17 16:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 23:31 [PATCH 0/6] cacheinfo: CPU affinity and Devicetree 'id' support Rob Herring
2021-12-16 23:31 ` [PATCH 1/6] cacheinfo: Allow for >32-bit cache 'id' Rob Herring
2021-12-16 23:31 ` [PATCH 2/6] cacheinfo: Set cache 'id' based on DT data Rob Herring
2021-12-17 16:57 ` Robin Murphy [this message]
2021-12-17 18:14 ` Rob Herring
2021-12-17 19:03 ` Sudeep Holla
2021-12-17 19:08 ` Sudeep Holla
2021-12-17 19:26 ` Rob Herring
2021-12-17 20:28 ` Jeremy Linton
2021-12-17 19:08 ` Robin Murphy
2021-12-17 19:35 ` Rob Herring
2021-12-17 20:22 ` Jeremy Linton
2021-12-17 21:13 ` Robin Murphy
2021-12-16 23:31 ` [PATCH 3/6] cacheinfo: Add cpu_affinity_map to store affinity for all CPUs Rob Herring
2021-12-16 23:31 ` [PATCH 4/6] ACPI / PPTT: Populate the cacheinfo.cpu_affinity_map Rob Herring
2021-12-16 23:31 ` [PATCH 5/6] cacheinfo: Use cpu_affinity_map for populating shared_cpu_map Rob Herring
2021-12-16 23:31 ` [PATCH 6/6] cacheinfo: Add cacheinfo_get_cache_affinity() function Rob Herring
2021-12-21 9:31 ` [PATCH 0/6] cacheinfo: CPU affinity and Devicetree 'id' support Greg Kroah-Hartman
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=881f056d-d1ed-c6de-c09d-6e84d8b14530@arm.com \
--to=robin.murphy@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=james.morse@arm.com \
--cc=jeremy.linton@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).