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 2CFD1C77B7A for ; Tue, 16 May 2023 08:20:12 +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=WTt1ZNDVSehioT+Stg4C6tNJiNyxeq8bHLNI3BzhMBs=; b=uMJtcrST0isiox 6HRwUFph2TuFMW+HdIHwIVngN6N3Wsp7+AgTM5m41fkbHvhbTQNhkyJHz5wif1Ev1nrqFeyebH+wf 52+xCJ2IeRGyb0mBMbICAYyHdU2Xfqm8LY2D+pls/LHBCiBtZvnvQ0dNiwxCTxJwBkxyhdOm7sV85 alWxYXnga0e3eFBT5zf5a/rOgaASBqwXmFfBNAYN/cztchYGOGorWWupwwsKkfMQA6VD0qfAtB9Xh PpiNFKrlB1oFL24AZ1lG2htnDs6mKqA6NOg+HC5N4MNFBhRWq/0wqyH39Xr9dqUM/GrAmhb7rHMdr 4VjL4i9ol7cHNE84xuGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pypuT-004p5q-03; Tue, 16 May 2023 08:19:53 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pypuO-004p2K-0F for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 08:19:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GpluGkfdMfUAqluklwPhF8EJ0GGm8Xs93dMxjtV521c=; b=txNr2DtWs8k8wHTEgrTrwbBh9T 7bcA2QjhcXm4vu7dQsoM7MJFNJWvyn3Qcs++Jir+Hc6cKlvEh6BGIwpMToN85mrpguvb2qlyMs6H0 OeOxRgqtlKXPdTOpv5ot034WsLmIWJSKXdJYrbTTTfkad4O79TywwLPa/3bJedL2YJRL1IEYQvD05 m8dO8hEpfSD990HswsxAYxwXocvC734MF2g9cOBaUyfzbBdeUPmkiqQSTM6Xi5KO1QfP+4xjlxfFH dgzo0gwcAlbV500p6N44D0IHWZyibsMsS9Iu+f6yPeSm7LMgCQ4cCjxUA+bLWps7bhB6bMzgy88hV mY0GoVoA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:49996) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pypuB-0005LR-Dg; Tue, 16 May 2023 09:19:35 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pypu8-0000e0-Jb; Tue, 16 May 2023 09:19:32 +0100 Date: Tue, 16 May 2023 09:19:32 +0100 From: "Russell King (Oracle)" To: Thomas Gleixner Cc: Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges Message-ID: References: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87r0rg93z5.ffs@tglx> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_011948_118500_355285DB X-CRM114-Status: GOOD ( 29.27 ) 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 Tue, May 16, 2023 at 08:37:18AM +0200, Thomas Gleixner wrote: > On Mon, May 15 2023 at 22:31, Russell King wrote: > > On Mon, May 15, 2023 at 11:11:45PM +0200, Thomas Gleixner wrote: > >> But that's not necessarily true for ARM32 as there are no IPIs involved > >> on the machine we are using, which is a dual-core Cortex-A9. > >> > >> So I came up with the hack below, which is equally fast as the full > >> flush variant while the performance impact on the other CPUs is minimally > >> lower according to perf. > >> > >> That probably should have another argument which tells how many TLBs > >> this flush affects, i.e. 3 in this example, so an architecture can > >> sensibly decide whether it wants to use flush all or not. > >> @@ -1747,7 +1748,12 @@ static bool __purge_vmap_area_lazy(unsig > >> list_last_entry(&local_purge_list, > >> struct vmap_area, list)->va_end); > >> > >> - flush_tlb_kernel_range(start, end); > >> + if (tmp.va_end > tmp.va_start) > >> + list_add(&tmp.list, &local_purge_list); > >> + flush_tlb_kernel_vas(&local_purge_list); > >> + if (tmp.va_end > tmp.va_start) > >> + list_del(&tmp.list); > > > > So basically we end up iterating over each VA range, which seems > > sensible if the range is large and we have to iterate over it page > > by page. > > Right. > > > In the case you have, are "start" and "end" set on function entry > > to a range, or are they set to ULONG_MAX,0 ? What I'm wondering is > > whether we could get away with just having flush_tlb_kernel_vas(). > > > > Whether that's acceptable to others is a different question :) > > As I said flush_tlb_kernel_vas() should be > > void flush_tlb_kernel_vas(struct list_head *list, unsigned int num_entries): > > So that an architecture can decide whether it's worth to do walk the > entries or whether it resorts to a flush all. Is "num_entries" what an arch would want to use? How would it use that? It doesn't tell an arch whether there is a large range of many list entries, or a single entry covering a large range. Wouldn't passing "start" and "end" allow an arch to check for a small range, and if the range is small, just call flush_tlb_kernel_range(). If the range is larger, then it can walk the list to decide whether it makes sense to flush by list entry. If it deems that it would be too much, then it could then flush all tlb entries. The down-side to that approach is its more arch-side code of course. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel