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:   Fri, 28 Jul 2023 14:50:50 +0100
From:   Conor Dooley <conor.dooley@microchip.com>
To:     Alexandre Ghiti <alexghiti@rivosinc.com>
CC:     Will Deacon <will@kernel.org>,
        "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Nick Piggin <npiggin@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Mayuresh Chitale <mchitale@ventanamicro.com>,
        Vincent Chen <vincent.chen@sifive.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        <linux-arch@vger.kernel.org>, <linux-mm@kvack.org>,
        <linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] riscv: Make __flush_tlb_range() loop over pte
 instead of flushing the whole tlb
Message-ID: <20230728-fragrant-slogan-c0d5fe419148@wendy>
References: <20230727185553.980262-1-alexghiti@rivosinc.com>
 <20230727185553.980262-4-alexghiti@rivosinc.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="jGn+lVFirgFk2Kkr"
Content-Disposition: inline
In-Reply-To: <20230727185553.980262-4-alexghiti@rivosinc.com>
Precedence: bulk

--jGn+lVFirgFk2Kkr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 27, 2023 at 08:55:52PM +0200, Alexandre Ghiti wrote:
> Currently, when the range to flush covers more than one page (a 4K page or
> a hugepage), __flush_tlb_range() flushes the whole tlb. Flushing the whole
> tlb comes with a greater cost than flushing a single entry so we should
> flush single entries up to a certain threshold so that:
> threshold * cost of flushing a single entry < cost of flushing the whole
> tlb.
>=20

> This threshold is microarchitecture dependent and can/should be
> overwritten by vendors.

Please remove the latter part of this, as there is no infrastructure for
this at present, nor likely in the immediate future.

> Co-developed-by: Mayuresh Chitale <mchitale@ventanamicro.com>
> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> ---
>  arch/riscv/mm/tlbflush.c | 41 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 39 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
> index 3e4acef1f6bc..8017d2130e27 100644
> --- a/arch/riscv/mm/tlbflush.c
> +++ b/arch/riscv/mm/tlbflush.c
> @@ -24,13 +24,48 @@ static inline void local_flush_tlb_page_asid(unsigned=
 long addr,
>  			: "memory");
>  }
> =20
> +/*
> + * Flush entire TLB if number of entries to be flushed is greater
> + * than the threshold below.

>     Platforms may override the threshold
> + * value based on marchid, mvendorid, and mimpid.

And this too, as there is no infrastructure for this the comment is
misleading. This kind of thing should only be added when there is
actually a mechanism for doing so.

I did say I would think about how to do this, but I have not come up
with something. I dislike using the marchid/mvendorid/mimpid stuff if we
can avoid it, as there's no control over what actually gets put in there,
especially if people are going to use the open souce cores.

Do we even, unless under extreme duress, want to allow setting custom
values here via firmware? Sounds like a recipe for 1200 different
alternatives or a big LUT...

--jGn+lVFirgFk2Kkr
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZMPHugAKCRB4tDGHoIJi
0i7gAQD99swFs11GEt+GGumHiBo4DwfAPprUIG6NJwlipUEtTwD8C0Cvcof0M2Cb
j9Yi7Bv2Lc/s1+bLZK+A2sqPkSyzRQ0=
=Z50k
-----END PGP SIGNATURE-----

--jGn+lVFirgFk2Kkr--