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 8EA06C77B7F for ; Fri, 19 May 2023 11:49:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B1D7900005; Fri, 19 May 2023 07:49:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16287900003; Fri, 19 May 2023 07:49:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 029A9900005; Fri, 19 May 2023 07:49:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E8150900003 for ; Fri, 19 May 2023 07:49:57 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B30CE120A53 for ; Fri, 19 May 2023 11:49:57 +0000 (UTC) X-FDA: 80806835634.11.FA93C3F Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf22.hostedemail.com (Postfix) with ESMTP id 11A27C000B for ; Fri, 19 May 2023 11:49:54 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="anpFlH/W"; dkim=pass header.d=linutronix.de header.s=2020e header.b=HIGP5RUO; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf22.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684496995; 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=/gl+WveyiZlpb6+4DFS5GDG6sgAY+Qor5hURVGk6SKg=; b=RlBTt7nQw8yFlegjMg4KZKBubtIiY+QfB9C9++aNpxSkEeR2Zef93BbDONKPr5VkdMiLTb 9aeFcAcFBG6Sa9xJd+4Bd2bUu4GoVt5KynyfKfa+ukhEtXTc2Nxlorq+mDv7Up/o8satt9 6JPUjUx/YK7OWnH/JsfS7lK2KJbcTJ8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="anpFlH/W"; dkim=pass header.d=linutronix.de header.s=2020e header.b=HIGP5RUO; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf22.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684496995; a=rsa-sha256; cv=none; b=jyl23+ITEhslUpYjp6tOzhYyWw9wEbGVZPMgCRRF3q0G2ofW7zcpMrGSLkrfwdQ9IwZxz0 60F5dmNaX4xO1ZPCKo7Vvu0gaH35GGifMjee1Q6Tg9D8xIfOdjOTY85IGFQLzPzudukb7+ NtXQEkHdn6tm1LV0HdlClVc51teJSBc= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684496993; 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=/gl+WveyiZlpb6+4DFS5GDG6sgAY+Qor5hURVGk6SKg=; b=anpFlH/WpylVc/rgeooyvcHPnwqcj1VUuupdqaoyXlqLndX1GU4M0CSKZQ9gSctQ/D+YUF K6V4lMts2fL4sG9DiH8FiSoxPsAvhQaQB6glQAb82Osh6sPkCzICfzVLDAugKriK715ldF Z6EVYdzpuEk1m1DvlmWnVyhauMumI1EPZpmlnPw8fZyFGwVDHdG65U+2NkQy5NZJ8Q64Fo ICBQjSKmB3wwZn+jqACUD5LZo7LCCfFZa5FfjgB7uMLR4hQL2qiqFb0IwyLxYkqc7Trm8L WiPU5xiLCiLR7IsTA5RRj6KfPqbT9xwNqruFzbrOt81wduIKBPQO5PX+/6i0mA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684496993; 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=/gl+WveyiZlpb6+4DFS5GDG6sgAY+Qor5hURVGk6SKg=; b=HIGP5RUOjbfysdEbXIH1W4NNpdH8MDtbeFJCMpI+clLeLi9dUH5E6XkMzFsgskcfbbU1W/ K/u8eVmyNowmVFDg== To: Nadav Amit Cc: 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, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges In-Reply-To: References: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <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> Date: Fri, 19 May 2023 13:49:52 +0200 Message-ID: <87353s5yn3.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 11A27C000B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: q3rm8xocd7tx8q3c36s4zgqrhi4tkqqf X-HE-Tag: 1684496994-129101 X-HE-Meta: U2FsdGVkX18JYUY33Wf3YOI1k69gcPWrt5l5nIjSA/QFbRR/Iwld50JtFwTGA7wqNpEZJAoRx6jp6KSn77nPkeeb+i8mM5S2lXFMUMAm3hYLeA5XqYzb52ZVQ7FnLInFFjKS1rcMjbZuRWcR4gI6t0+0HgMjmPnXZbz7Uk0qooG2HQjpIyZvgUHyxyBqomFJZU8YdelyOaz1c0DvKwAI4Okz1/IYgAd6Q6sm1PZs4mXvikfQA7LiW8MaCgL3qRWTqjOGUTBanRCekZ64B1eT6QCwOxrzQqPGEA/NMxA36HeCFXWfATmve4Yg7qafEn9JjeuiTjpWoC1FRALC9qi7zqGMmLQvKMqdeZijfmSFaQgFCUQmGcBiOms4IuM5oXGj3Ul52CmVqkXDAFxcxyg8/GdxYiIANGq1IaHaVk8FLAXzkJqvr6njhgcjoKtkehyNJisTrPfyiZJeGRlhvbg/1RzbBO0RMzKBzX65kGR0yhjOExkn+Y0d6DGxLqV5tn5hh/UzYZ0Wxropp4YRo4Y5TaRiftKCYTIRN24lGu5uRnx5jGsLOLz+Gr4OQCfIa1hC8glN64F7TOSlZAEI6iZiVf6k+aIaZ6wtNT4flIuf6v4SmLQ4iIP3X6VWsFuhroSZnywCWbqIfwIST/mxPvl5SoVlj1rLl6+8wsUfs3LCE41HgCN7BDrvPeW7tDJs2DEFjANS/iXvEVrBhlSa1GThDm+pxj2kWhuQBZTHWn6js9JXAyMNZ9XOco7+fMf/NPiMJ8ctL7/3eumjY0s0fo2Ush6HF10tBz1ynXEo9fHti4D2zCoOVyFjYq/DcTcIpyFhvLZSQ1hhzgh9DJmVjRzLQeF+ExNVFi48kPFVZGaFksexy/NMhQrgYp/9mgiyw1qcelPS7yvUejPospAfzq4xdpRFYU+q4N9L0xkzCjWUzvDsrOb+QJmIiawBsq64CxuMTChysEfwLh5rnfpxESz 7MKd9bgV aLLiNlGWIjYGK4AGZ79FxJLrbFOrcf4jGfnwv5L50p/lVZbN4MKSlAcpZLMB/nnJVizgKzHDd4y9AnoGogXIBQnn5Sd6g9NRDyFz6+uKQlZvjxQ1yJ/6WzzIQIl591+kCj4NzGc5lrt9fei1Y3+fUwXJ/tTd+Y9L+0/wO2Om67FwRYPJlsUOfBEowOHkWZFll3lzt/iuxFihoO4M= 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 Wed, May 17 2023 at 15:57, Nadav Amit wrote: >> On May 17, 2023, at 3:31 AM, Thomas Gleixner wrote: >> Maybe ARM[64] could do this smarter, but that would require to rewrite a >> lot of code I assume. > > What you say makes sense - and I actually see that flush_tlb_page_nosync() > needs a memory barrier. > > I just encountered recent patches that did the flushing on ARM in an > async manner as I described. That is the reason I assumed it is more efficient. > > https://lore.kernel.org/linux-mm/20230410134352.4519-3-yangyicong@huawei.com/ This operates on a mm and is related to batched removal of user space mappings. That could be done for vmalloc too, but the life time tracking, i.e. ensuring that a nosync flush has seen the final barrier which ensures that the mapping is not longer visible might be slightly more tricky. Especially with the full x86 centric code there. Thanks, tglx