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 4D30CC77B7F for ; Tue, 16 May 2023 17:06:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D32FA900004; Tue, 16 May 2023 13:06:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE312900002; Tue, 16 May 2023 13:06:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD234900004; Tue, 16 May 2023 13:06:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AF98E900002 for ; Tue, 16 May 2023 13:06:32 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3A148AD8D8 for ; Tue, 16 May 2023 17:06:32 +0000 (UTC) X-FDA: 80796747024.28.67CA575 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf13.hostedemail.com (Postfix) with ESMTP id 3F56820309 for ; Tue, 16 May 2023 17:04:37 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="C/T8AYk5"; dkim=pass header.d=linutronix.de header.s=2020e header.b=bj3fpWqd; spf=pass (imf13.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684256678; 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=i9sTBEhlrLDGw7XOo39QXte9kwHa2ppgB3KPnFarf2Y=; b=jVr1HUsHHo0yzdmlYnP51Z/OIUS1Y3Ii5yaA3xQKnwA7mgALp0mgQri5uOeVsx0ozk9WVk eWk7sDRZ8mdl4hiFVlmw3OCLBX4PwEzKrvYBu1nKNXGVGYW3agDZ/Z3mm2tXQ3IAO18mu7 Sc0/fYPYi3KSUfQF494nKvb519NF8Ps= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684256678; a=rsa-sha256; cv=none; b=DRSbPHGq7oilJs52o9PqqTzpBeiu1DIq7VXXf3OcqC/6iqf3YJ2xe7FH2R8qDODoTUXGwF TSUsCUwXUj9uEhG+gC5llYOyjdsCE3s+jIe3Bp3Qmtd1BHbHw/TZ7iuprL7ODZIPzhjSvX TskdW8eOyPkkAzCs0wDBPkjwVuRumyE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="C/T8AYk5"; dkim=pass header.d=linutronix.de header.s=2020e header.b=bj3fpWqd; spf=pass (imf13.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de 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 Content-Type: text/plain X-Rspamd-Queue-Id: 3F56820309 X-Stat-Signature: pcbkxm7tjjju988nj6s9bm1zpakhk7sn X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1684256677-282015 X-HE-Meta: U2FsdGVkX1+0JCGnFGylOUVgB4KjlFIeLgyxXmE8snAIPJpoOGarpHQtCzExDwOPS4J3hjVg6kClXNR8vp5YWuzT1WQsh9Ia+hg1JMvrc7aAAvMcjMLlIQHvpgJHji8EfHbsq0dSksCGVk9CJN8/3cetmXsuhB3G8szb9wz5XJ0dltj4lYutri5CpXO9+MXwTKGYrqeRq+pXt4BY0xmQFFWcrsR/sWxZHHwx3UtALhN4YrM4aMtEwUSBJGq48kQahuulQm2KG1cQetab9d36L5SEYNQ1ucge65YNozuoZUnZeOfsc0ru09DJ/xx52MvaS5PhWBwVxuuDWbsLxaY35EwDr+m7MpBAijEYV/pu90BudiswH559MBHAd5Qjsd410nMxM90n6pcEzGc6W2FWpsASw3uTWF470C5o0kFFhwmGIQXPkTAJfczo5BUjPHd5uM8TJThC9T7yxpO/H+2OTu644ESFG5Xr+nUGNESjFwjZpy2YuBun2PR4EEVA8Bh3zFIraGFhk7wj6H+nWFR5nCmQ0+tlno4IMlugMoS/yeQK2c/2kXJaCbuIq2b48bSvsjdeVa4RPDG25ErkikcFIC9MRR7670PP+E/qRpmfaUc3cekHbXxvIuy+q9weaHlzTk1bANuF76Db4hC8Q/dnwrBZkLHfVMfYl3V5LdW7IO6D3M/WHRZSt9DC1aEX/nGluG6DEqyagta/jaZ/H4iUnbsoDIMXsxN8T+SAzSmG5g+wvf9VSp1OmZVbg52iqIeQVRBIAwZOLmZsDRaMd07eLa+oLTBPxm73UETAWrCGZLfRxqlK1KDjP3OEcta+AKXFntTiHDBWNhmSy8rsqq/QVJvn1ME+UuGRQvGplbGm3KdpDytm5YmW8Doiek6lP9ySb4OK0hfTnZQW22PAr+r8wqGSKhe/PTttOs0WqD2WIdEGSj26zauM5Vq6+lqediykOBEM0dcW4XxvtIJqctO 3uTyxFdH H3J9cO3X+ORBPbKBWPDdCRe9q+1SxRJk1r5dSbgeDqpiMngY= 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: 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