All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor.dooley@microchip.com>
To: Pierre Gondois <pierre.gondois@arm.com>
Cc: <linux-kernel@vger.kernel.org>, Radu Rendec <rrendec@redhat.com>,
	Alexandre Ghiti <alexghiti@rivosinc.com>,
	Will Deacon <will@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Palmer Dabbelt <palmer@rivosinc.com>,
	Gavin Shan <gshan@redhat.com>,
	Jeremy Linton <jeremy.linton@arm.com>
Subject: Re: [PATCH v2 1/3] cacheinfo: Check sib_leaf in cache_leaves_are_shared()
Date: Wed, 12 Apr 2023 12:27:20 +0100	[thread overview]
Message-ID: <20230412-viewpoint-refutable-a31f3657093c@wendy> (raw)
In-Reply-To: <20230412071809.12670-2-pierre.gondois@arm.com>

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

On Wed, Apr 12, 2023 at 09:18:04AM +0200, Pierre Gondois wrote:
> If 'this_leaf' is a L2 cache (or higher) and 'sib_leaf' is a L1 cache,
> the caches are detected as shared. Indeed, cache_leaves_are_shared()
> only checks the cache level of 'this_leaf' when 'sib_leaf''s cache
> level should also be checked.

I have to say, I'm a wee bit confused reading this patch - although it's
likely that I have just confused myself here.

The comment reads "For non DT/ACPI systems, assume unique level 1 caches,
system-wide shared caches for all other levels".
Does this mean all level 1 caches are unique & all level N caches are
shared with all other level N caches, but not with level M caches?
(M != N; M, N > 1)

Is this patches goal to make sure that if this_leaf is level 2 and
sib_leaf is level 1 that these are not detected as shared, since level
one caches are meant to be unique?

The previous logic checked only this_leaf's level, and declared things
shared if this_leaf is not a level 1 cache.
What happens here if this_leaf->level == 1 and sib_leaf->level == 2?
That'll be detected as shared, in a contradiction of the comment above
it, no?

As you never state the actual problem with the current code, I'm not
entirely sure if I am making a fool of myself or not here.

Probably making a fool, that's par for the course ;)

Thanks,
Conor.

> 
> Check 'sib_leaf->level'. Also update the comment as the function is
> called when populating 'shared_cpu_map'.
> 
> Fixes: f16d1becf96f ("cacheinfo: Use cache identifiers to check if the caches are shared if available")
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
>  drivers/base/cacheinfo.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index f3903d002819..e7ad6aba5f97 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -38,11 +38,10 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>  {
>  	/*
>  	 * For non DT/ACPI systems, assume unique level 1 caches,
> -	 * system-wide shared caches for all other levels. This will be used
> -	 * only if arch specific code has not populated shared_cpu_map
> +	 * system-wide shared caches for all other levels.
>  	 */
>  	if (!(IS_ENABLED(CONFIG_OF) || IS_ENABLED(CONFIG_ACPI)))
> -		return !(this_leaf->level == 1);
> +		return (this_leaf->level != 1) || (sib_leaf->level != 1);
>  
>  	if ((sib_leaf->attributes & CACHE_ID) &&
>  	    (this_leaf->attributes & CACHE_ID))
> -- 
> 2.25.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-04-12 11:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12  7:18 [PATCH v2 0/3] cacheinfo: Correctly fallback to using clidr_el1's information Pierre Gondois
2023-04-12  7:18 ` [PATCH v2 1/3] cacheinfo: Check sib_leaf in cache_leaves_are_shared() Pierre Gondois
2023-04-12 11:27   ` Conor Dooley [this message]
2023-04-12 12:34     ` Pierre Gondois
2023-04-12 12:47       ` Conor Dooley
2023-04-12 13:20         ` Pierre Gondois
2023-04-12 13:50           ` Conor Dooley
2023-04-12  7:18 ` [PATCH v2 2/3] cacheinfo: Check cache properties are present in DT Pierre Gondois
2023-04-12  7:55   ` Conor Dooley
2023-04-12  8:12     ` Pierre Gondois
2023-04-12  9:38       ` Alexandre Ghiti
2023-04-12  7:18 ` [PATCH v2 3/3] cacheinfo: Add use_arch[|_cache]_info field/function Pierre Gondois
2023-04-12 11:47   ` Conor Dooley
2023-04-12 12:35     ` Pierre Gondois

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=20230412-viewpoint-refutable-a31f3657093c@wendy \
    --to=conor.dooley@microchip.com \
    --cc=alexghiti@rivosinc.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gshan@redhat.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=palmer@rivosinc.com \
    --cc=pierre.gondois@arm.com \
    --cc=rafael@kernel.org \
    --cc=rrendec@redhat.com \
    --cc=sudeep.holla@arm.com \
    --cc=will@kernel.org \
    /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 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.