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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 59E4EC77B7D for ; Wed, 17 May 2023 14:44:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZsiWpbMfsxFNGaw34kf5kyk9U/3veKFKeziB2U++Mk4=; b=P+VBIPAasJjnhd xsuz3gVkgAKbOTsJuKi33Qow53wW17vSpGWFNuYb47cd8lwW8WxL6hwtTPChl8tpGptuhqv0MoM2x b0f85XwP8GMqWgW7No80YTrAAEka0rZ8C1S8kXjZr1YyQF80ehegixKssIhM8fT2FBMz6UGRFFtPR DcbQfXaavKcHGZTJnMasLS8+A2PLCACsdHIlZx8xki/h0EtggX2hyI0bn+UW+A2Yr+JopcSMwXOfr o9NvVAOupbAl1Qg45Avm7pYxKEQ/qsro/Pcm9XvtWjkICmU0x5A73p75Eek5b9zQRVS84SRlxR5Uq P1wRHAEnUcWM6yI9S2NQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzINh-00AAXk-1g; Wed, 17 May 2023 14:43:57 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzINe-00AAVH-0i for linux-arm-kernel@lists.infradead.org; Wed, 17 May 2023 14:43:56 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EDD511FB; Wed, 17 May 2023 07:44:31 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.32.153]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 38BC73F73F; Wed, 17 May 2023 07:43:45 -0700 (PDT) Date: Wed, 17 May 2023 15:43:36 +0100 From: Mark Rutland To: Thomas Gleixner Cc: Nadav Amit , Uladzislau Rezki , "Russell King (Oracle)" , Andrew Morton , linux-mm , Christoph Hellwig , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges Message-ID: References: <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> <7ED917BC-420F-47D4-8956-8984205A75F0@gmail.com> <87bkik6pin.ffs@tglx> <87353v7qms.ffs@tglx> <87ttwb5jx3.ffs@tglx> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87ttwb5jx3.ffs@tglx> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230517_074354_352934_6F28309D X-CRM114-Status: GOOD ( 19.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 17, 2023 at 12:31:04PM +0200, Thomas Gleixner wrote: > On Tue, May 16 2023 at 18:23, Nadav Amit wrote: > >> On May 16, 2023, at 5:23 PM, Thomas Gleixner wrote: > > My experience with non-IPI based TLB invalidations is more limited. IIUC > > the usage model is that the TLB shootdowns should be invoked ASAP > > (perhaps each range can be batched, but there is no sense of batching > > multiple ranges), and then later you would issue some barrier to ensure > > prior TLB shootdown invocations have been completed. > > > > If that is the (use) case, I am not sure the abstraction you used in > > your prototype is the best one. > > The way how arm/arm64 implement that in software is: > > magic_barrier1(); > flush_range_with_magic_opcodes(); > magic_barrier2(); FWIW, on arm64 that sequence (for leaf entries only) is: /* * Make sure prior writes to the page table entries are visible to all * CPUs, so that *subsequent* page table walks will see the latest * values. * * This is roughly __smp_wmb(). */ dsb(ishst) // AKA magic_barrier1() /* * The "TLBI *IS, " instructions send a message to all other * CPUs, essentially saying "please start invalidating entries for * " * * The "TLBI *ALL*IS" instructions send a message to all other CPUs, * essentially saying "please start invalidating all entries". * * In theory, this could be for discontiguous ranges. */ flush_range_with_magic_opcodes() /* * Wait for acknowledgement that all prior TLBIs have completed. This * also ensures that all accesses using those translations have also * completed. * * This waits for all relevant CPUs to acknowledge completion of any * prior TLBIs sent by this CPU. */ dsb(ish) // AKA magic_barrier2() isb() So you can batch a bunch of "TLBI *IS, " with a single barrier for completion, or you can use a single "TLBI *ALL*IS" to invalidate everything. It can still be worth using the latter, as arm64 has done since commit: 05ac65305437e8ef ("arm64: fix soft lockup due to large tlb flush range") ... as for a large range, issuing a bunch of "TLBI *IS, " can take a while, and can require the recipient CPUs to do more work than they might have to do for a single "TLBI *ALL*IS". The point at which invalidating everything is better depends on a number of factors (e.g. the impact of all CPUs needing to make new page table walks), and currently we have an arbitrary boundary where we choose to invalidate everything (which has been tweaked a bit over time); there isn't really a one-size-fits-all best answer. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel