Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 12 Apr 2023 14:50:01 +0100
From:   Conor Dooley <conor@kernel.org>
To:     Pierre Gondois <pierre.gondois@arm.com>
Cc:     Conor Dooley <conor.dooley@microchip.com>,
        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()
Message-ID: <20230412-catalyze-putt-4a0d48042e4f@spud>
References: <20230412071809.12670-1-pierre.gondois@arm.com>
 <20230412071809.12670-2-pierre.gondois@arm.com>
 <20230412-viewpoint-refutable-a31f3657093c@wendy>
 <d7a36615-896b-0f13-a1f6-761715ce460f@arm.com>
 <20230412-hut-unused-21d683fcb8b0@wendy>
 <b87130ba-b3c2-825c-0e2c-634e8aee8d5c@arm.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="31Nhce6gARzTUXUy"
Content-Disposition: inline
In-Reply-To: <b87130ba-b3c2-825c-0e2c-634e8aee8d5c@arm.com>
Precedence: bulk


--31Nhce6gARzTUXUy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 12, 2023 at 03:20:19PM +0200, Pierre Gondois wrote:
> > On Wed, Apr 12, 2023 at 02:34:11PM +0200, Pierre Gondois wrote:

> > Another silly question:
> > For two caches of level M & N; M !=3D N; M, N > 1 should they be detect=
ed
> > as shared in the absence of any information in DT/ACPI?
> > The comment (to me) reads as if they should not, but it is rather vague.
>=20
> I think they should. The naming of cache_leaves_are_shared() might be
> misleading. The function is more trying to find out if 2 cache leaves str=
uct
> are representing the same cache. So maybe renaming the function to
> cache_leaves_identical() might be better?

Nah, I don't think this is really the fault of anything other than the
!DT && !ACPI situation.
I'm just trying to make sure I understand the intended behaviour in that
scenario, that's all.

> If there is no DT/ACPI, it is not possible to identify whether 2 cache le=
aves
> are representing the same cache. The desired behaviour is just:
> - If this_leaf or sib_leaf is a L1 cache, then the caches are not identic=
al
>   (or shared if we use this wording)

> So the meaning of cache_leaves_identical() is a bit bent for this
> configuration.

Fair enough.

--31Nhce6gARzTUXUy
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZDa3BgAKCRB4tDGHoIJi
0vrcAQCW6Qv7JEnbOaLRCie9bWqvTjhTS9wIpR4saBeeRVODrAEA8WU4D22dkSnN
K5Zhe/I9KdRpdhwCHiO1hBJaBHUdago=
=7IKn
-----END PGP SIGNATURE-----

--31Nhce6gARzTUXUy--