Message ID | 20250220052027.58847-5-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 1E694C021AD for <linux-mm@archiver.kernel.org>; Thu, 20 Feb 2025 05:20:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC898280296; Thu, 20 Feb 2025 00:20:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BDAAA280294; Thu, 20 Feb 2025 00:20:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A54B7280296; Thu, 20 Feb 2025 00:20:44 -0500 (EST) 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 64651280294 for <linux-mm@kvack.org>; Thu, 20 Feb 2025 00:20:44 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E50DE120B4C for <linux-mm@kvack.org>; Thu, 20 Feb 2025 05:20:43 +0000 (UTC) X-FDA: 83139173166.26.13F7ED2 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf22.hostedemail.com (Postfix) with ESMTP id 13797C0002 for <linux-mm@kvack.org>; Thu, 20 Feb 2025 05:20:41 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740028842; a=rsa-sha256; cv=none; b=x+Sy5kYo91zH3/gwRa7Qm1vjDgqDXjc/5kneawQEH56Hz2myb5Vhvsb+uL975nH6O1Al5U 1sF++EEs+Hm6Ig8uYUeszCx/DD8WdUiT5ayqUUZc7/Ul4UIxprO8Or9mllK/j9mlND7ipV EHmiCjT//iT33D7jJWvP9YT47G8wwjo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740028842; 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=CU9nQq9JQzZA9ZYPcb+lZt8ZPs+raz4pWESYoIMpHZc=; b=OmClifZiaajCceAJmc1UlNCEQYEfUfX4OZWoy+NG4HorrnmlYFGmCrnk0Bqctj/IdudazO 345rRIGKs1xsRAE3G3593id6Q0VUdcJfcpEEDQfLT74ENgNERpXgOSOa0uCr8nVCFl1LWF XviGDlE9QgYD7JHQ40/mnVa4Cs0a+l8= X-AuditID: a67dfc5b-3c9ff7000001d7ae-bf-67b6bba6b39a 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, ying.huang@intel.com, 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, dave.hansen@linux.intel.com, rjgolo@gmail.com Subject: [RFC PATCH v12 04/26] x86/tlb, riscv/tlb, mm/rmap: separate arch_tlbbatch_clear() out of arch_tlbbatch_flush() Date: Thu, 20 Feb 2025 14:20:05 +0900 Message-Id: <20250220052027.58847-5-byungchul@sk.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20250220052027.58847-1-byungchul@sk.com> References: <20250220052027.58847-1-byungchul@sk.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsXC9ZZnoe6y3dvSDfb+FbeYs34Nm8XnDf/Y LF5saGe0+Lr+F7PF0099LBaXd81hs7i35j+rxflda1ktdizdx2Rx6cACJovjvQeYLObf+8xm sXnTVGaL41OmMlr8/gFUfHLWZBYHAY/vrX0sHjtn3WX3WLCp1GPzCi2PxXteMnlsWtXJ5rHp 0yR2j3fnzrF7nJjxm8Vj3slAj/f7rrJ5bP1l59E49Rqbx+dNcgF8UVw2Kak5mWWpRfp2CVwZ Z288Yil4ylcxafI8tgbG2TxdjJwcEgImEv++3mGFsVfvXsoGYrMJqEvcuPGTGcQWETCTONj6 hx3EZha4yyRxoB+ohoNDWKBcYs0sPxCTRUBV4uktVZAKXgFTictfWhghJspLrN5wAGwKJ9CU HzN6waYLAdW8W3CJqYuRC6jmM5tE963rUCdIShxccYNlAiPvAkaGVYxCmXlluYmZOSZ6GZV5 mRV6yfm5mxiBYb+s9k/0DsZPF4IPMQpwMCrx8M5o3ZYuxJpYVlyZe4hRgoNZSYS3rX5LuhBv SmJlVWpRfnxRaU5q8SFGaQ4WJXFeo2/lKUIC6YklqdmpqQWpRTBZJg5OqQbGagPJ7Zt9xZsn 626cPF0wizV9rsuiZ0WaXSc4pogo+J+dOHvfvNg/Yf+fTRJv99soeam8JdDC7mCKm8CiZydf q8fvLND++czCd+q9iKUeF9aGL/vUNuOy1nWe2c4C+gmr7V8tKz6RY8IpnNX/+chT1/It6xXV 52vHKezyi/o36fTCROXbmzzXKrEUZyQaajEXFScCAFaoSSN3AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsXC5WfdrLts97Z0g9MP+SzmrF/DZvF5wz82 ixcb2hktvq7/xWzx9FMfi8XhuSdZLS7vmsNmcW/Nf1aL87vWslrsWLqPyeLSgQVMFsd7DzBZ zL/3mc1i86apzBbHp0xltPj9A6j45KzJLA6CHt9b+1g8ds66y+6xYFOpx+YVWh6L97xk8ti0 qpPNY9OnSewe786dY/c4MeM3i8e8k4Ee7/ddZfNY/OIDk8fWX3YejVOvsXl83iQXwB/FZZOS mpNZllqkb5fAlXH2xiOWgqd8FZMmz2NrYJzN08XIySEhYCKxevdSNhCbTUBd4saNn8wgtoiA mcTB1j/sIDazwF0miQP9QDUcHMIC5RJrZvmBmCwCqhJPb6mCVPAKmEpc/tLCCDFRXmL1hgNg UziBpvyY0Qs2XQio5t2CS0wTGLkWMDKsYhTJzCvLTczMMdUrzs6ozMus0EvOz93ECAziZbV/ Ju5g/HLZ/RCjAAejEg/vg8db04VYE8uKK3MPMUpwMCuJ8LbVb0kX4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzusVnpogJJCeWJKanZpakFoEk2Xi4JRqYLQ5vFln2+xUHd+QVxJOv7PWGchsd9lm du7eT/3HdrdcVacJr7sc63vT52PH3NbERVe5fLwefAzqV/E0O7WvgdvY//Upht/fyg70WMTG aWz/fVjgRnhE8uwfXc6a4Sk/63ccK12X+pyPeS/nhQqpwvwnVRt/H22JfVLvfImp+23P7hPs 6qrztiuxFGckGmoxFxUnAgBEHJIWXgIAAA== X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 13797C0002 X-Stat-Signature: i9eixu33db55e849y7819gb48hsy7t4b X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740028841-748411 X-HE-Meta: U2FsdGVkX1/eJInT2P3URBG+pAp2wem33lAXwfD/aaLmrKgm6fYruTfxFj8sVN1tC/fguNYlWuhF7nnNoF87scXljKB2QWKwiioazzJC4GJov0Q3whunIy4+0pEJx08f5MC1WR0dJKknhK9TDf2nLkCwjkG+bZqF1B8a5KTYcMV9wkKTgRLYUMo5IS4M2ZFezDUuZ5cN3AGh6m33rPvjuxTIYhZp30UfIege7agXVrqzJP0FpJdonIkJ7tGt2i2AfiygSSR7PZIFa5OMtAOkRzSzgcCuYYTy2yxT6gEEhh0rmugTDzqz/0emDSFtrdqnaDbJ6KJSrf/Jx9fylGYUlkgn5HutdawiSJSSNPo9ldsCEduvxM7d5L0rLCP9/5zTxCAiZtzlA5R91dyXhZO9RWEuJjiTcH3Kn9guVPY0BTQbew9yfjXFLg24X/1nQpzZEzPRXum9/sH0NZqawTHXJuP3CCOghTapFB7jjN9q9Ba8hO/AvnXQ3157Y5fLlmtLDj5qIcRe/0kP0ADX4cAF5GqMnnc4L418qP6vSzx7odEoPiw/xfnuW0NZfFS5fMIT/mISNM/7moeWGa64g0XPzdN/xhnz7wXaenstfqZsyqaVDldZdp7oHybckXi0rEMBI0j1wKj3VlHI1XxMJdGS7ig2o8vxVp84Yl3JZkqWWas/Oo6PtJcGnqVlGJ1gUbSkAW18I4EMoiAUkidIhU7NMOS8X6MrGoLcLHq7k0vk0hj5d+GuUtuGaGoL/VkDMraH6OujdlFpwjU5uz6HxYjeTN1WkvDo6AfQE/4F/eW2ByFUSoAHKJAu9KeqQYjh2wBGUKTaEHxCN4OV27pr+nntZb1iYsgalqO0wjtpbWOWffbzL4sz5Sr9kMgqTSzV09LkJtrmTyoV/p8k6reoGHpAlrwDg/8uCOppD4f6Xh+pybbWO/S9N6rmWVPP6GW0gcYFPtkRR6a4at/95jUHhqK qd8swbIg zfPrGdMLdCymQ4O9oBcc6HivSaLgeLY4Qu5Bz 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 |
LUF(Lazy Unmap Flush) reducing tlb numbers over 90%
|
expand
|
diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c index 9b6e86ce38674..36f996af6256c 100644 --- a/arch/riscv/mm/tlbflush.c +++ b/arch/riscv/mm/tlbflush.c @@ -201,5 +201,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 86593d1b787d8..860e49b223fd7 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -1262,8 +1262,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 c6c4d4ea29a7e..2de01de164ef0 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(-)