From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D460AC001E0 for ; Fri, 28 Jul 2023 13:51:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 395768D0003; Fri, 28 Jul 2023 09:51:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 346318D0001; Fri, 28 Jul 2023 09:51:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20CFF8D0003; Fri, 28 Jul 2023 09:51:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 123F78D0001 for ; Fri, 28 Jul 2023 09:51:33 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DBEF9A1111 for ; Fri, 28 Jul 2023 13:51:32 +0000 (UTC) X-FDA: 81061158024.18.688F072 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233]) by imf04.hostedemail.com (Postfix) with ESMTP id 7FC8B4000C for ; Fri, 28 Jul 2023 13:51:30 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=microchip.com header.s=mchp header.b=ageU6UTb; dmarc=pass (policy=quarantine) header.from=microchip.com; spf=pass (imf04.hostedemail.com: domain of Conor.Dooley@microchip.com designates 68.232.153.233 as permitted sender) smtp.mailfrom=Conor.Dooley@microchip.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690552290; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C+qgGG8kK8apCYAL7jHt46TTa6xBPAiksqn/Pj732rQ=; b=3JVeVPP0VoX9+FDoQak1FChZGckK0xuB7bttTB5SaJaFou65O5uGnwslyTnxcchdfg2NNm rlKA+5+OZady9kZkngQGOv53anCoW3ESqe8kz70p9E5ov8/V0krN2Sxk+mM+a0ZZhZJ76K A5133CXhvI0VuNPg8ux9xzwBJgaZc0c= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=microchip.com header.s=mchp header.b=ageU6UTb; dmarc=pass (policy=quarantine) header.from=microchip.com; spf=pass (imf04.hostedemail.com: domain of Conor.Dooley@microchip.com designates 68.232.153.233 as permitted sender) smtp.mailfrom=Conor.Dooley@microchip.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690552290; a=rsa-sha256; cv=none; b=HU7bz5KGOlF90hkoII0Y3Se3nlmG2vpH+taCBSHaNnAttKVThyROfieFs802YyhI2OpnrJ N3eeDva0OEVmmtK8Uz0G7fOiiIql8lrOpwLUltilt4LhtGmUeZBt2Y3cKpZhxlJR7Rg68k l1n9npnlEdB0kTQuBbd3qlWXH1b14aM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1690552290; x=1722088290; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=u4UOOMLzhEg7Hb9YLlX0MpaOBGLEhWTvCIPPPEtSP78=; b=ageU6UTbQu6Brx0Zp84M2aRUVAJnpC3ZZlE0PPGNIzisSXKnyXXrpQs4 ZDCozVWL+8zLg4cKx/Wbq0jZG598SQbeKebVqbjYZK40nhIln8sQsxD6n e4N+SPs6npUMEsnuAU097+F5D5z5W9d9cjEK2UMdduhx6i4XF1El0hDPa ivWHmFAR58PWA56ZPTGtOQ0yHj+8kh02pbsG/PF7pq95Khei+MZ5xjkAg Tdy/MZgedL4Zk+0LglMCKpkCOUd1e7jmYWCfxqcRIZM8M/Wm941kHE+AQ TY3c0a1j67IY4VYTOKi+mo45L4nhMqK+7UXC47dbWDw3/X3zggN9axScN Q==; X-IronPort-AV: E=Sophos;i="6.01,237,1684825200"; d="asc'?scan'208";a="238439247" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa1.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 28 Jul 2023 06:51:28 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Fri, 28 Jul 2023 06:51:27 -0700 Received: from wendy (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21 via Frontend Transport; Fri, 28 Jul 2023 06:51:25 -0700 Date: Fri, 28 Jul 2023 14:50:50 +0100 From: Conor Dooley To: Alexandre Ghiti CC: Will Deacon , "Aneesh Kumar K . V" , Andrew Morton , Nick Piggin , Peter Zijlstra , Mayuresh Chitale , Vincent Chen , Paul Walmsley , Palmer Dabbelt , Albert Ou , , , , 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> X-Rspamd-Queue-Id: 7FC8B4000C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: pocyq8zumfo9t44ghyi5ouwfs8xwpxde X-HE-Tag: 1690552290-588568 X-HE-Meta: U2FsdGVkX1+DT/bBBNsKoQOhpuqgvk6MHiu12ZSrsCIQ4XaXdVQTp16fXKG7DU9a7LokXAjAjY4QzVfNViZgS4gGw6GN7zj9WBaHBi6rAYDzWLqkrU5jCfgEjTp7IKlZhxS9MgwyfdR5g2z3UcShzE4vre7Dmm1tG07uL9Gn6ioJbpK4whHVBEXPhTlhSSLlGAcG2wUiUTFBH4RFauXTdJyAb28cxn84ALn2pY0Em01qtIHSRmBXnCzgnfYi6tUhRt0bC9bI1pb1jsjKUmmJYEKqK3RFkk5V3lV6ByuzgAZwgP0QbpoYbR5fSRz5RmA7OCN+qH7ZezVPnKZOKbaH5Y1/qj7DQgSNQlZgms4IoUq+SMi/zfUENG/dqCzl5Cn6junzQiHS4749KKbFVo1acvF4Wlfg4YzEVcH5eewnRkLrFzDcGbCdWT+76pDOvDJVb6N6r93xdXkczcZhPiSzOghsvaYdIYwgDprwM6O4OTIDCvLucTYZD4Bq1MoaDxAwjzG+g1dFctplLDvzP9OL3ey0FuZK2brBGrg71D3rDII3zKjwpperZymFHE1X7OTaBBexcqdtmW1+QEDhOhOAFdemWWniekRduJmGSFFBHCH7THDatylyESL2r2/BdAQbaD07d4lmBdKzfL70O1hex3CBXdTHtoI337Q2rM8C91IZzHgaqAm4cAiRnZwzjFSs46M9lGFa/r+2nsfPuXMjJgBBJFkPImYJFXBhGhu18k4GU3Aq9EGFYkwc8ZAng3Mvbz8YwXE9mN1aLR0ZoJeeJ9jE30JReOC+KBHhGEsAVtQMyLTQhe35Bfi0tlIplqy6KGNAhY+qyZhKM9owmofkdbECn6EYnDAOEW7IYcut9hXT3Y5qxMC0wpuXrUpCBITpZPILmQVSSjVTleJhFyAeS5EIEWA+cdV68ZIThCp9AM7cVaSKbwkK0/kjyHWdqyztUIc+nWYbK5K3efZpLUn PMy8vP2u jv5yhhKiCu69QFYXkiPChrCowDIhH4H/gh5HliKPQCYiukpr8/ARKlcPUY4h9fake7fIe7+XUc47C7S+vf/DdJx9uayxonlKMp7d6c7q9aBejmhamXLvmJg0WrZ1w0bLR9LxaEt9HOwzpjKmJiUENUi0xN5WTaoIRWxa/QjAwRYsxOJ8gqiJNMz13puP1329d71+GiBS9grEsSiHltDdfX3Qef0Em/TzMgFXddywDmU8rFFa2N1oGCy0PRa7KcQbWIy5TVoCdP6NKyccKsGCl5akiS26JQXEpV1El+el8YlEknoIL4BwNEgnoubAP/hrNtZTn6LO7pWr44dK+yRWGp8qmbhR3ecqeWEx4eIq1XFQ6/hXp84SSCLd3tRhU+b2sJ4yL1BgWtsXRYpx7DHemD3y3DG9YAwJeRhjcwNMRrndHI1v/9EIyHo3B6XEyH3YTKBetcPOGmRLPiHzhlSUj7hP+iSN9jX5YALCQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --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 > Signed-off-by: Mayuresh Chitale > Signed-off-by: Alexandre Ghiti > --- > 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--