From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outbound.qs.icloud.com (qs-2001h-snip4-3.eps.apple.com [57.103.87.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB7A02BE7BE for ; Mon, 20 Jul 2026 05:07:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=57.103.87.76 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784524075; cv=none; b=SaFXbUcobSF9eHhLtmfM7zTQQs0kxFMrgiwt3hHRQPDkpMV4Ta5LVoL2yo9o5/tSyWjSaRrCjOK4mwJXxVAQXGF69VfiXI5ojwQrM88L4JVdZBGaBWy32PoyNxXI6Eu5SgVLfw+q2iu3KGWur4sEWcgFqugPWmvlQw9w65/Copw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784524075; c=relaxed/simple; bh=Zop4bLuKGY4EXfmtgnIN25YeRP2tMQYyb08aLDvFxlI=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=XDWp7dQVc3K/ymD0umNeVGO66GjOKhRRdbxpM0ilqvudugIKjvsjlFdu36+0dH7lDfWgcvq40cHo3FIsv57q0BfZmDswmCU/VmEbkWBPyHgLs1yHlRiXJx3+PR2sOOuQ3DTUPTR07oz+7HVvSrinyrluPe7PiiTElQVUOtsT75o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com; spf=pass smtp.mailfrom=icloud.com; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b=lHOFL3u2; arc=none smtp.client-ip=57.103.87.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=icloud.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b="lHOFL3u2" Received: from outbound.qs.icloud.com (unknown [127.0.0.2]) by p00-icloudmta-asmtp-us-east-2d-60-percent-7 (Postfix) with ESMTPS id E8F691800105; Mon, 20 Jul 2026 05:07:50 +0000 (UTC) X-ICL-RepId: 019f7dec-6004-78c9-bc25-08be6376e19a X-ICL-Out-Info: HUtFAUMEWwJACUgBTUQeDx5WFlZNRAJCTQhMHVwGXRxCCkEdXgBLVxQEAlodRw5AHVYWWAhOK1sTVRdGCRkIXR0ZHldQXgheH0wcHQ5YBhICWkUBXRcDVxxWRVwYQwldBVccHRxERVsTVRdGCRkIXR0ZCEcfCjADQg5WA0MHRQAtGRxXUF4IXh9MHB0OWAYSHVAcDlEFWwBGCU8BXRoJUwRaEB4ZWwkfFlUNQAUaHQddCVVXDw5fAREJHAMJAQlyGVoUXBhTRVEfVEYTGU4bV01QG18CQg8= Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1784524072; x=1787116072; bh=Faah87vbG2GYUTT4eqViFuxusWFFNof64ld9zeyq33w=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:x-icloud-hme; b=lHOFL3u2/cCUBMIkacRG+0ZdK85P3yDqpgxeBC7wk24a4VA+zFdS4B2yV2Rs9QlFeQtmvwcV5a8cC856TBVlBXrQ4EPmRJigjdkJrRe51XrLOfp15P90zD26tshxLd9D45UVN9hwNWvO3Lt52/gzM9rBX11nDxHK4EfXvSkKQlxKYwAxfJcDURRSwIa1dvm5UyHIKt0TC4TmTz+3aMBtZPemVRtZISOUnG9MhScj4sjXewWKthvzkM7iW+2RmUWjkdvTNBaHAp61BI4KrgHAwTRRgvhiIYunrG0jUM48IPmUgP/RVbDbGki/e3FkHh824FTBBXyJavJXuX8XojMqyw== Received: from [21.6.122.162] (unknown [17.57.155.37]) by p00-icloudmta-asmtp-us-east-2d-60-percent-7 (Postfix) with ESMTPSA id 10BF3180009C; Mon, 20 Jul 2026 05:07:44 +0000 (UTC) From: Zhang Peng Subject: [PATCH v5 0/5] mm: batch TLB flushing for dirty folios in vmscan Date: Mon, 20 Jul 2026 13:07:37 +0800 Message-Id: <20260720-batch-tlb-flush-v5-0-db943a0d0d6b@icloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIABmtXWoC/3XNTW7DIBCG4atErEs1MEBMV71HlAU/Q4zkxpGxr USR716STVqhLN9PmmfurNCUqbCv3Z1NtOaSx3MN/bFjoXfnE/EcazMJ0gCC5d7Noefz4HkaltL zzmIC0sYra1i9ukyU8vUpHo61+1zmcbo9H6zisb63VsGBk+8SxX0UztJ3DsO4xM8w/rAHtso/g DQtICugAElLRKmDagB8AUpAC2AFUgJvIzrUwjWAegFa6hZQFehw39lonA8A/4Bt234B21JFc3I BAAA= X-Change-ID: 20260309-batch-tlb-flush-893f0e56b496 To: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Michal Hocko , Qi Zheng , "Liam R. Howlett" , Qi Zheng Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Kairui Song , Zhang Peng X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1784524064; l=6066; i=zippermonkey@icloud.com; s=20260309; h=from:subject:message-id; bh=Zop4bLuKGY4EXfmtgnIN25YeRP2tMQYyb08aLDvFxlI=; b=bvrZ2TAzja8w975UPXyeyf+3/CKdznk/k58Ik06iZLmK1bkIL9rF6idOYGQZLyxvZnFVRvyQ3 gzqQA63pNt7D+6GwkSCCnGudZb+bHRtaVUFhXWih9GwRb2FFUBPdVEE X-Developer-Key: i=zippermonkey@icloud.com; a=ed25519; pk=tPCLpFnBfIyHsp0k7eaUTUREEa36bQNW/69X+NS8wBU= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIwMDA1NCBTYWx0ZWRfX6x1mN5KQ40cw i9ASRQfKj5SIlyxieqgxTmVVWpJRJNyGq94Pu4yUAu7hX6KwRgOwEiVwtDKnbRoD1USkYUVnZQC PNhSXX5ywSSQhqdNV46vorD94tDlHocZCmY7LC+PhGlydWfTUpRH3/feiNSvASQtIT8MLRCWCkk 44PbFYKE2jb7GcOW/HkKWBP2Jr/ojdxmxF2vnLHYDacKRys+fyMAcaxQuhxufcc4u6V63A4MzMf PyaHRQ1eKJuVe9SAVwR1/UP6ggIK8sy5qMkPOISNV2lBVEwW9KB3zMhBJQfs0pEm4ui7+4kNh7G XlOUa7UD5CJVhN5Qyhd X-Proofpoint-ORIG-GUID: WgQ5csdCtwnSb1QqCn-nwVaHcFFfnm38 X-Proofpoint-GUID: WgQ5csdCtwnSb1QqCn-nwVaHcFFfnm38 This series introduces batch TLB flushing optimization for dirty folios during memory reclaim, aiming to reduce IPI overhead on multi-core systems. Background ---------- Currently, when performing pageout in memory reclaim, try_to_unmap_flush_dirty() is called for each dirty folio individually. On multi-core systems, this causes frequent IPIs which can significantly impact performance. Approach -------- This patch series accumulates dirty folios into batches and performs a single TLB flush for the entire batch, rather than flushing for each individual folio. Changes ------- Patch 1: Extract the folio activation block at activate_locked into folio_activate_locked(). Patch 2: Extract the folio-freeing path (buffer release, lazyfree, __remove_mapping, folio_batch drain) into folio_free(). Patch 3: Extract the pageout() dispatch state machine into pageout_one(). Patch 4: Extract the TTU setup and try_to_unmap() block into folio_try_unmap(). Patch 5: Implement batch TLB flushing logic. Dirty folios are accumulated in batches and a single TLB flush is performed for each batch before calling pageout. Testing ------- The benchmark script uses stress-ng to compare TLB shootdown behavior before and after this patch. It constrains a stress-ng workload via memcg to force reclaim through shrink_folio_list(), reporting TLB shootdowns and IPIs. Core benchmark command: stress-ng --vm 16 --vm-bytes 2G --vm-keep --timeout 60 ========================================================================== batch_dirty_tlb_flush Benchmark Results ========================================================================== Kernel: 7.0.0-rc1+ CPUs: 16 MemTotal: 31834M SwapTotal: 8191M memcg limit: 512M alloc: 2G workers: 16 duration: 60s -------------------------------------------------------------------------- Metric Before After Delta (abs / %) -------------------------------------------------------------------------- bogo ops/s 28238.63 35833.97 +7595.34 (+26.9%) TLB shootdowns 55428953 17621697 -37807256 (-68.2%) Function call IPIs 34073695 14498768 -19574927 (-57.4%) pgscan_anon (pages) 52856224 60252894 7396670 (+14.0%) pgsteal_anon (pages) 29004962 34054753 5049791 (+17.4%) -------------------------------------------------------------------------- Suggested-by: Kairui Song Signed-off-by: Zhang Peng --- Changes in v5 (addressing David Hildenbrand's review on v4): - Patch 1: Drop the nr_pages parameter; use folio_nr_pages() inside folio_activate_locked(). Add VM_WARN_ON_ONCE_FOLIO(!folio_test_locked) at the top of the function. Turn the VM_BUG_ON_FOLIO(folio_test_active) into VM_WARN_ON_ONCE_FOLIO and move it to the top. - Patch 2: Rename folio_free() to folio_try_reclaim_free() to make the reclaim-specific role clear and justify the bool return. Make nr_pages const. Add VM_WARN_ON_ONCE_FOLIO(folio_ref_count, folio) at the free_it: label. Drop the now-redundant "swapped out as a whole" comment and the "else continue" after goto keep_locked. - Patch 3: Rename pageout_one() to folio_try_pageout() for consistency with the other helpers. Fix continuation-line alignment. - Patch 4: Fix continuation-line alignment. - Patch 5: Replace the in-place folio_batch_reinit() + walk pattern with a plain local array; @fbatch is now only read during the walk and cleared once afterwards, so its invariant is never temporarily broken. Add a comment documenting why each recheck (writeback, mapped, dma_pinned) is required. - Link to v4: https://lore.kernel.org/r/20260525-batch-tlb-flush-v4-0-83789d6abc00@icloud.com Changes in v4 (addressing Barry Song's review on v3): - Drop the "track reclaimed pages in reclaim_stat" patch; keep shrink_folio_list() returning nr_reclaimed directly. Avoids touching the function signature and its MGLRU evict_folios() and reclaim_clean_pages_from_list() callers in this series. - Rename folio_active_bounce() to folio_activate_locked(). The new name reflects the precondition (the folio is locked) that callers care about. - Split the folio_free()/pageout_one() extraction into two patches; make pageout_one() return bool so shrink_folio_list() can see whether the folio was reclaimed or kept. - Move the !folio_mapped() check out of folio_try_unmap() into the caller, so folio_try_unmap() is only invoked for mapped folios. - Link to v3: https://lore.kernel.org/r/20260410-batch-tlb-flush-v3-0-ff0b9d3a351a@icloud.com Changes in v3: - Patch 5: Replace folio_test_lru() condition check with VM_WARN_ON_FOLIO assertion, as PG_lru should never be set for isolated folios - Patch 5: Add comment explaining folio_batch reuse-in-place technique in pageout_batch() - Patch 5: Rewrite comment above folio_unlock() to explain why the folio is unlocked while batching - Link to v2: https://lore.kernel.org/r/20260326-batch-tlb-flush-v2-0-403e523325c4@icloud.com Changes in v2: - Fix incorrect comment about page_ref_freeze - Add folio_maybe_dma_pinned() check in pageout_batch() - Link to v1: https://lore.kernel.org/r/20260309-batch-tlb-flush-v1-0-eb8fed7d1a9e@icloud.com --- Zhang Peng (5): mm/vmscan: introduce folio_activate_locked() helper mm/vmscan: extract folio_free() from shrink_folio_list() mm/vmscan: extract pageout_one() from shrink_folio_list() mm/vmscan: extract folio unmap logic into folio_try_unmap() mm/vmscan: flush TLB for every 31 folios evictions mm/vmscan.c | 455 ++++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 293 insertions(+), 162 deletions(-) --- base-commit: d0b709f436b2788a10407624688ab8327c5ce18d change-id: 20260309-batch-tlb-flush-893f0e56b496 Best regards, -- Zhang Peng