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 1EF50C77B75 for ; Tue, 16 May 2023 17:05:00 +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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1yHRkdueLwbq5ZvRWOzohnk7vK2MewYK2JPF+hndb5I=; b=BDSGVCu79Zy1xF GtEfqVdgequ3BdWJf54iJ1u2VKn4FoYuOjg0LIDyeOxRBSS23xNIwgpzP11OZBWhx7KxVtHRY4EtE HB5zdBt319gyt/LWtDGMOJ73xBNB47JqARJyHXTFKERqLf7rBkslD5P/+jn1pycZkqRC9XyYfd0pM D2+9VgjatU61jF6HMungQQB47uoRrLaQA0spw1pbagna3LkJ2vHWt1VVjyRiCg56qbk+Ar2KJU+nX HqBAA73U5qWnC4ii/8yvqv+QcWxChGdFZiPk2LsFmOiAuKX5SigQLYMJm/oUPhOeaNXnEc00vGa60 xtUMemaRNLZ2Xezb79Xw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyy6M-006ZbJ-0C; Tue, 16 May 2023 17:04:42 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyy6J-006ZYs-0X for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 17:04:40 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684256675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i9sTBEhlrLDGw7XOo39QXte9kwHa2ppgB3KPnFarf2Y=; b=C/T8AYk57EIqTm88hbU4EHIfuK98AHY/nKMLUBzWv8OTGkJZTv88+J/Fz+Hi9A8K/zaHgB RTBEO4k3L21GHBNwKw3MFJiKVpfeJr+tgYtMao/s+B/yxoTNHesj7HZJ1/CW/JR1ssCq4T NMRDLFk74a2NMl9+3bsMFPruDdiQHUNig8wfPEp70R/KunPbysLYiDPEq2f8EZkmjYWwXB h+Mb58xfK7ZsP7yfdco6PrgdZQBi7YO2/OcpmCv2LwkTklNxJRFFGUuq3K52VLfB8vE4o1 u0VVtG3RoUJK3c1mLlFl+wnr770dr1pq+KLLlj6JMZogBtrU2e/eC4NnThCRPQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684256675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i9sTBEhlrLDGw7XOo39QXte9kwHa2ppgB3KPnFarf2Y=; b=bj3fpWqdi9wiMnuxq/wTeiTp4tBzncGKxjk1dF1v6f+XtWX6TfasEVY1XSsfk7QUoXNBpt qs+g5vYkd638iJAA== To: Uladzislau Rezki Cc: Uladzislau Rezki , "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , 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 In-Reply-To: References: <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> Date: Tue, 16 May 2023 19:04:34 +0200 Message-ID: <87leho6wd9.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_100439_346239_DC2B7922 X-CRM114-Status: GOOD ( 14.30 ) 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 17:01, Uladzislau Rezki wrote: > On Tue, May 16, 2023 at 04:38:58PM +0200, Thomas Gleixner wrote: >> There is a world outside of x86, but even on x86 it's borderline silly >> to take the whole TLB out when you can flush 3 TLB entries one by one >> with exactly the same number of IPIs, i.e. _one_. No? >> > I meant if we invoke flush_tlb_kernel_range() on each VA's individual > range: > > > void flush_tlb_kernel_range(unsigned long start, unsigned long end) > { > if (tlb_ops_need_broadcast()) { > struct tlb_args ta; > ta.ta_start = start; > ta.ta_end = end; > on_each_cpu(ipi_flush_tlb_kernel_range, &ta, 1); > } else > local_flush_tlb_kernel_range(start, end); > broadcast_tlb_a15_erratum(); > } > > > we should IPI and wait, no? The else clause does not do an IPI, but that's irrelevant. The proposed flush_tlb_kernel_vas(list, num_pages) mechanism achieves: 1) It batches multiple ranges to _one_ invocation 2) It lets the architecture decide based on the number of pages whether it does a tlb_flush_all() or a flush of individual ranges. Whether the architecture uses IPIs or flushes only locally and the hardware propagates that is completely irrelevant. Right now any coalesced range, which is huge due to massive holes, takes decision #2 away. If you want to flush individual VAs from the core vmalloc code then you lose #1, as the aggregated number of pages might justify a tlb_flush_all(). That's a pure architecture decision and all the core code needs to do is to provide appropriate information and not some completely bogus request to flush 17312759359 pages, i.e. a ~64.5 TB range, while in reality there are exactly _three_ distinct pages to flush. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel