Message ID | 20250226120132.28469-4-byungchul@sk.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 01D18C18E7C for <linux-mm@archiver.kernel.org>; Wed, 26 Feb 2025 12:01:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27B2528001C; Wed, 26 Feb 2025 07:01:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F134280021; Wed, 26 Feb 2025 07:01:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1A9728001D; Wed, 26 Feb 2025 07:01:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 709CC28001C for <linux-mm@kvack.org>; Wed, 26 Feb 2025 07:01:49 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CE18FA34B2 for <linux-mm@kvack.org>; Wed, 26 Feb 2025 12:01:47 +0000 (UTC) X-FDA: 83161956696.28.DCE01C8 Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf12.hostedemail.com (Postfix) with ESMTP id 2DDD440045 for <linux-mm@kvack.org>; Wed, 26 Feb 2025 12:01:43 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740571305; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=XXYoBnHoyfeoAmGg+EzfxFy8YoEa8sPs3rLTgmZBeC4=; b=DgXe3KEjaZum/iopVmtgPsAMmkuactYSRJckW5b4e4AbRgQv0A0BSWlrvj9lFzJ6j4mtCQ yYMN5R922roLR16+gl3qOuI0uC3pkYjgNeES7jzRArPYgbimvh1EN1pws2265MvFQhn6yZ lFd+5h3aqfrBwmPBqZuUxl93UabQ1xo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740571305; a=rsa-sha256; cv=none; b=lzOIgTT7ulSJkmkoQhgIyADUBsGKVzh56RoeLjjFzcGYFGTc+hKyC1oZkmCQ0vrxCBHsFp lIN7yf/Cqj/ResyXIYauqu9Gq30hqV8ehFhmhNQRua7L+jmYIUOwleavjKTF0+wmQqtIQf 3s+Sf5uigRMWgjBUE4lxeiJgdjY2H70= X-AuditID: a67dfc5b-3e1ff7000001d7ae-d6-67bf02a660b4 From: Byungchul Park <byungchul@sk.com> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: kernel_team@skhynix.com, akpm@linux-foundation.org, vernhao@tencent.com, mgorman@techsingularity.net, hughd@google.com, willy@infradead.org, david@redhat.com, peterz@infradead.org, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, rjgolo@gmail.com Subject: [RFC PATCH v12 based on mm-unstable as of Feb 21, 2025 04/25] x86/tlb, riscv/tlb, mm/rmap: separate arch_tlbbatch_clear() out of arch_tlbbatch_flush() Date: Wed, 26 Feb 2025 21:01:11 +0900 Message-Id: <20250226120132.28469-4-byungchul@sk.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20250226120132.28469-1-byungchul@sk.com> References: <20250226113342.GB1935@system.software.com> <20250226120132.28469-1-byungchul@sk.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsXC9ZZnke4ypv3pBrPWSlrMWb+GzeLzhn9s Fl/X/2K2ePqpj8Xi8q45bBb31vxntTi/ay2rxY6l+5gsLh1YwGRxvPcAk8X8e5/ZLDZvmsps cXzKVEaL3z/msDnweXxv7WPx2DnrLrvHgk2lHptXaHlsWtXJ5rHp0yR2j3fnzrF7nJjxm8Xj /b6rbB5bf9l5NE69xubxeZNcAE8Ul01Kak5mWWqRvl0CV8b+y5+YC57yVWxduompgXE2Txcj J4eEgIlEW18fC4w98UMPI4jNJqAucePGT2YQW0TATOJg6x/2LkYuDmaBZUwSe080sIE4wgIL GCUmdExiBaliEVCVeHyuH6ybV8BUYseKtUwQU+UlVm84ADaJE2jSv92/2UFsIYFkiZb1v1lA BkkI3GeT+L/wCtQZkhIHV9xgmcDIu4CRYRWjUGZeWW5iZo6JXkZlXmaFXnJ+7iZGYGAvq/0T vYPx04XgQ4wCHIxKPLwPzuxNF2JNLCuuzD3EKMHBrCTCy5m5J12INyWxsiq1KD++qDQntfgQ ozQHi5I4r9G38hQhgfTEktTs1NSC1CKYLBMHp1QDY7HkV05O7lkN/henvV58qGZeNq97j3eH sYDs1zk83/44887KKO1m+Bakque+IOqIXVzgvaxtD7t29uwK+2TB/ejPc54pHxYdla+O+bLC Rbd3ffS6NU+uT/mxgpPtboDusgN6puy/1n02aaxdsXbB1tfbAp6dVldrf+kalHBB6OTp3W3f 7leeXqPEUpyRaKjFXFScCACeUCQdaAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsXC5WfdrLuMaX+6QdtRAYs569ewWXze8I/N 4uv6X8wWTz/1sVgcnnuS1eLyrjlsFvfW/Ge1OL9rLavFjqX7mCwuHVjAZHG89wCTxfx7n9ks Nm+aymxxfMpURovfP+awOfB7fG/tY/HYOesuu8eCTaUem1doeWxa1cnmsenTJHaPd+fOsXuc mPGbxeP9vqtsHotffGDy2PrLzqNx6jU2j8+b5AJ4o7hsUlJzMstSi/TtErgy9l/+xFzwlK9i 69JNTA2Ms3m6GDk5JARMJCZ+6GEEsdkE1CVu3PjJDGKLCJhJHGz9w97FyMXBLLCMSWLviQY2 EEdYYAGjxISOSawgVSwCqhKPz/WDdfMKmErsWLGWCWKqvMTqDQfAJnECTfq3+zc7iC0kkCzR sv43ywRGrgWMDKsYRTLzynITM3NM9YqzMyrzMiv0kvNzNzECw3RZ7Z+JOxi/XHY/xCjAwajE w/vgzN50IdbEsuLK3EOMEhzMSiK8nJl70oV4UxIrq1KL8uOLSnNSiw8xSnOwKInzeoWnJggJ pCeWpGanphakFsFkmTg4pRoYH/MVal/dc/ZRh3WVpNLHhXz/anq8+3cZ9XZomr2VXZY549/a ZS/cil7znjqlxDOxwd5pRtd2w9cVXNzT/5+2EAiZaLM7TqziuvGpiSaOafINeqxHO5NYvaVv HJ4TUnxk1uXo5SJsy3UfrGUVmXNgz6NPFcuuy5v+9K2sOfRi1habCqb1+aJeSizFGYmGWsxF xYkAF+3NiE8CAAA= X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 2DDD440045 X-Stat-Signature: e7feb99tdy46pcgyp5hh1a6szuc1zt36 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740571303-387100 X-HE-Meta: U2FsdGVkX1+sxe4gHh6BG1WUZ+SzyyHrBBIqlK9w5CV2fWXj4fyJeQ1xHX1wL+cs2j0bcwrCw+Nc+/OIH8XCEj+E+FH2IOIZtfeYJMDnUZOYDEW4OwLWl/trNrXAcrFZTLbJXG5ljjlDRLlT3U+s1P2chDb/VaON1EUceklr1+3UlMyL/DJmxcTv59djMSnl0KxkWq3ZGnx3mevkEK8qmM9S47t4qgGfP6UXUWZihsFd0qtr6y3Sgh4RutVz+q/xTlVsgMRryoUR+sdB58vo9ulvdVears/eaGYGEY7t7tuNqnh8cucgedt+HIEzLxYuY2r0R+9+gDHKT5p/kS0inVYkX0pJfGdwV6tL1jVkLdBxI6pKaj8dsSrVcg+z9F2te5a4f1mNMx9hgf+95hRJYSMbMA3CEghm+OYp2VwwsOzIKTDKpl5r9y45R1csR3s8iV34BXoNBzPBzKA/wgoM7yqbifCEDmymvaAWbqRWs9zvB92usNhCzcH7GGNvX8ruVvZbhGKoCHfYM2Uq7fh/HgYI2Yhh3VMX1cMiZ3zx0Zv4qY/83vikqAkoH0gQ+xBGFMbxntOnc3w5Aj2nJ2oCfaCs1xjTDDcUbBx6WIWkyVZpNxq0DQl8/XMAXnqyum5Qz8K9MLjNYKeZT681lBcWjq/zWEc3hScXVtTYzuXEkrO2kwDFrcQvqCXOJxcHp7xvnl9Hsd5SY4T+jnUQL49coghdeHI8gotLvbbroXJMrDs1iszTBHtWYuFgwDGmRebT21dkWycr/6oREPWarADLM5PC+gXcDa8IalyXQ2o14Qc4PG41GeTbvy+44Wuk/E5rPodIDvsa2GBqpe+g2qUy1Gug9OG6DC0+fKcOxH5TVVc4yWt15WwO/RLMdPolFiFFTJmJ0IQgbV2qU9K0wegsG4wL+fdksOsf6Sa9EriKVrbFAHiOEgoao3NzKnlt9ZazJJ2VrA9lw7KDsNfYKVL roJikwma le3yArwAko1l7+4k1GwmVsiC3GVUpnpkvSJ4Q3nCZigyJ9CFdFnQ11+N093hEbJpaHz7r 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
[RFC,v12,based,on,mm-unstable,as,of,Feb,21,2025,01/25] x86/tlb: add APIs manipulating tlb batch's arch data
|
expand
|
diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c index 74dd9307fbf1b..38f4bea8a964a 100644 --- a/arch/riscv/mm/tlbflush.c +++ b/arch/riscv/mm/tlbflush.c @@ -200,5 +200,4 @@ void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch) { __flush_tlb_range(&batch->cpumask, FLUSH_TLB_NO_ASID, 0, FLUSH_TLB_MAX_SIZE, PAGE_SIZE); - cpumask_clear(&batch->cpumask); } diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 6cf881a942bbe..523e8bb6fba1f 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -1292,8 +1292,6 @@ void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch) local_irq_enable(); } - cpumask_clear(&batch->cpumask); - put_flush_tlb_info(); put_cpu(); } diff --git a/mm/rmap.c b/mm/rmap.c index bcec8677f68df..546b7a6a30a44 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -648,6 +648,7 @@ void try_to_unmap_flush(void) return; arch_tlbbatch_flush(&tlb_ubc->arch); + arch_tlbbatch_clear(&tlb_ubc->arch); tlb_ubc->flush_required = false; tlb_ubc->writable = false; }
A new mechanism, LUF(Lazy Unmap Flush), defers tlb flush until folios that have been unmapped and freed, eventually get allocated again. It's safe for folios that had been mapped read only and were unmapped, since the contents of the folios don't change while staying in pcp or buddy so we can still read the data through the stale tlb entries. This is a preparation for the mechanism that requires to avoid redundant tlb flush by manipulating tlb batch's arch data. To achieve that, we need to separate the part clearing the tlb batch's arch data out of arch_tlbbatch_flush(). Signed-off-by: Byungchul Park <byungchul@sk.com> --- arch/riscv/mm/tlbflush.c | 1 - arch/x86/mm/tlb.c | 2 -- mm/rmap.c | 1 + 3 files changed, 1 insertion(+), 3 deletions(-)