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 CAB8FC77B7D for ; Mon, 15 May 2023 16:43:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E477900003; Mon, 15 May 2023 12:43:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 394BF900002; Mon, 15 May 2023 12:43:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2833A900003; Mon, 15 May 2023 12:43:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 166C1900002 for ; Mon, 15 May 2023 12:43:46 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C4E61160F49 for ; Mon, 15 May 2023 16:43:45 +0000 (UTC) X-FDA: 80793060810.28.1415865 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf06.hostedemail.com (Postfix) with ESMTP id 07825180004 for ; Mon, 15 May 2023 16:43:43 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=y63P0Tvr; dkim=pass header.d=linutronix.de header.s=2020e header.b=Ja5EEyFS; spf=pass (imf06.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=1684169024; 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: references:dkim-signature; bh=hFJvl7LIktbBCQ1SyA1NJ2Cms/GCM39PTTVcTkrL/sU=; b=XjCNK7PzuFe4DR5JD2SaR6yUsdC3SkrOpX9F4RJ+9HbyINn5g+GN6dPtn8QBN2SDC/m4A/ tQeTNCBPn+ub6249IuscYgPbhGdvDnhK3hPF7/RKX4Zd1bYpJizCnpzGx4NAZ3ekK9rFT2 s4K5Uq0criJYs6gWTJdB9ktp3GH5W88= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=y63P0Tvr; dkim=pass header.d=linutronix.de header.s=2020e header.b=Ja5EEyFS; spf=pass (imf06.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684169024; a=rsa-sha256; cv=none; b=EshFOCeC+L91ZVhgvzpTWROEM5TOmfMAQDj/eqNat40BBEMXEv9WF7s0GJK63x14Aj/dCQ /YHEZvU6xN+JWNIOq3ZCvRGOrbg4GX9XW1x9EJkZg6icTmK2eLlwbdXd9Ym6FDmwgJMrSF 4X40z9vpiRlI1bO5qUQPRhSvnpG6RVs= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684169021; 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; bh=hFJvl7LIktbBCQ1SyA1NJ2Cms/GCM39PTTVcTkrL/sU=; b=y63P0Tvr5peIGLAfqQ3o8V4fFS8LbGVupCFXakDXRKbt1HOBb4qSeDkmIYiYC8NrcNcQxH SBCCRHY/k/PhVfOPzUok7NkRLWIAZ3HnQt3SPhv0DVxFgqnlsSgf9p9e7gvauHFpikRxpJ jNRLuKPlYWwOUtSm7P/m8wxyDNHbNrPCiTyN1zgSRBp0ZgaGPlA9gXIcUw1SUGTEmvK2tk IqSf12G60ylzlcX8YWqRa4z3BC3pRAG28fen1nbPiRkTQMe5LbPxPfzL9tDw4/NVNLDSJ3 SxKf6L2oU6/OlSOPnh3kunY6DGR1jamkBM+z40DYgsbqSNoFWT/9GlUsfBgACQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684169021; 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; bh=hFJvl7LIktbBCQ1SyA1NJ2Cms/GCM39PTTVcTkrL/sU=; b=Ja5EEyFSWzhxflA9/YmV4Dt0KlDUvunOlw9bTerG1NcVQhAllHubMnc6a4dSIn4qyCFUa2 Ya/gi+Jyj0M2AaBw== To: Andrew Morton Cc: linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Russell King , Mark Rutland , Marc Zyngier Subject: Excessive TLB flush ranges Date: Mon, 15 May 2023 18:43:40 +0200 Message-ID: <87a5y5a6kj.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 07825180004 X-Stat-Signature: zugxc6fetqx9dfrksggbuouu9n3urniy X-HE-Tag: 1684169023-35834 X-HE-Meta: U2FsdGVkX18x8LbS10H1oeb8WeBojonuOxHCj34zaMzSaXQ/kGV9XhWG8rdv+Frmu7ZoKizrGVW/19QroVK82777AnoGbA0Z0utq32i/hNvlKTAYA8rcTAsxock8xp0Pssyvt6rNYZZf4UAmgAtw3CfDHa93qT1CRBda1sZ9g3MQJ5ZKInjkicLpGXnIbkzQ9dmQY9eOWRC1CNZmB6mS9cNUajgvpXIL1FIUDGLvZYNcn/xkEgLk2i7OWPzx1fGTHoNeVdjz7ttw9z0lLydn+9GaQyPu1K2cioU6aB76lsRvvJ/V6RfXwhKfFsAkyrTPWiXv+H/zU0qh1TKGiQNZjiDYR8GudZv4yyhhWhQA6vkPIcPlzTOyG3+7VlXIpR7VB1soRxWLaZeAc75X8w4seB4apY4G8s9B7Dhdh/nKYI7t1rBdzrBtNz+gHHutpX/4JKKcJ7rlEC5UpyMHjh2PcfUj/TN/vnEEAhUhZWLTpithrU8z4b1LM2t3D2Zc0taAka6R9dXJobwfCbdwk01imIePr6M8lI8Jj7QZ91Kp1ZH5kK3tdTTC6tSzM2Q+ius1ZdupA5JxenPVTtoOgTxaESPrhWFay7nl6e2zrbUm65lIjqPVJPTey6ln6/vbz9V6rOf/XJ/VOJOLrjgqaFRkwfTQ7cCWJ4ZRX5GFDlCEuhSM81BxQahAqCMri8l2Wl4zzzON2a1aWHca/ShDzVmdWFzJF3R0vr+hs4a79zN+/AAT11OZc3Mi+9fRlgRdd8pMfhNMaX61jUHzzDZpcZsIfKtDMJSaaY7xWjrkQGztlEB/FDSDQ6NrRUOOvn9A2jKbLaTZbWc7sQyAQKIz7nFiwLFyZmNhtXBVXS7yNemLj2G27jzMVpPP1CXMT8Tx/FmK3dz+8VxIIM3WyMWtktEIBQ5QqKtyzS2WJzMBs5QaLQ0R7PPNqxETSybfWx/6xrcjdrM04DjQruxC6F/AQ5I 73hwZBFT qyR2sKS4PP4qodzYE0H5UEWjTuWOMAQoPtQgcGuWpxEGI7gp1OlXzlMCI9w== 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: Folks! We're observing massive latencies and slowdowns on ARM32 machines due to excessive TLB flush ranges. Those can be observed when tearing down a process, which has a seccomp BPF filter installed. ARM32 uses the vmalloc area for module space. bpf_prog_free_deferred() vfree() _vm_unmap_aliases() collect_per_cpu_vmap_blocks: start:0x95c8d000 end:0x95c8e000 size:0x1000 __purge_vmap_area_lazy(start:0x95c8d000, end:0x95c8e000) va_start:0xf08a1000 va_end:0xf08a5000 size:0x00004000 gap:0x5ac13000 (371731 pages) va_start:0xf08a5000 va_end:0xf08a9000 size:0x00004000 gap:0x00000000 ( 0 pages) va_start:0xf08a9000 va_end:0xf08ad000 size:0x00004000 gap:0x00000000 ( 0 pages) va_start:0xf08ad000 va_end:0xf08b1000 size:0x00004000 gap:0x00000000 ( 0 pages) va_start:0xf08b3000 va_end:0xf08b7000 size:0x00004000 gap:0x00002000 ( 2 pages) va_start:0xf08b7000 va_end:0xf08bb000 size:0x00004000 gap:0x00000000 ( 0 pages) va_start:0xf08bb000 va_end:0xf08bf000 size:0x00004000 gap:0x00000000 ( 0 pages) va_start:0xf0a15000 va_end:0xf0a17000 size:0x00002000 gap:0x00156000 ( 342 pages) flush_tlb_kernel_range(start:0x95c8d000, end:0xf0a17000) Does 372106 flush operations where only 31 are useful So for all architectures which lack a mechanism to do a full TLB flush in flush_tlb_kernel_range() this takes ages (4-8ms) and slows down realtime processes on the other CPUs by a factor of two and larger. So while ARM32, CSKY, NIOS, PPC (some variants), _should_ arguably have a fallback to tlb_flush_all() when the range is too large, there is another issue. I've seen a couple of instances where _vm_unmap_aliases() collects one page and the actual va list has only 2 pages, which might be eventually worth to flush one by one. I'm not sure whether that's worth it as checking for those gaps might be too expensive for the case where a large number of va entries needs to be flushed. We'll experiment with a tlb_flush_all() fallback on that ARM32 system in the next days and see how that works out. Thanks, tglx