From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0D5C21ABB1 for ; Sat, 21 Feb 2026 09:39:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771666789; cv=none; b=puHD69uwLdu2H/BXHAuQCJvwOxVmX9I+/6vpJwuQJ+Py4bw79ZUk1/WSQAVHeM+u4dJ+5GCLnfxTSnhfDv3lY06XTQu4qDNNepckjxrwLk9o+wchuE3r+ZjmArKGTC1CHtxBg7P84KGYTuqPLLVCNASD63PilFG0bHOYXTKKMr0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771666789; c=relaxed/simple; bh=K3ueF+wP8sTBaiTnxYter5LO/ADwFP4zYUnqjjLmTuk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=YSRvp6AiOTwnqPmFPccLILyspao9ASExGDhdryi8wZkoxEd/5z8k1vufkjMd66cnYrp7FM42t+rqUWsj6bR1sLNJ0pkAOj/W2f5KM0eZILf09CJqsm4jL1PLM0JuoLjlE8qYwNZy3cTgEJVDnj93tXWWxakRFIwE4MSxvcURsnM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NlpZuk9r; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NlpZuk9r" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-823081bb15fso1678954b3a.3 for ; Sat, 21 Feb 2026 01:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771666787; x=1772271587; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=r8HSfiLjyaGOvsXQk4UfGGYxPYIXKUkZDXPSFYlRGr0=; b=NlpZuk9rjDAgiNQO67Ls4Yte/w6RgI1htfNLt1HX0LCp7hZCEEeTEeEKdq5tdNkyOQ WfUVp4gWnKE7rs9AcUU///U4ZSrldL1KIpfjODPUlR6uR7qqEjWOagT970LNGpLYXmwe 06mbrrTs7TP8MddDVRbAZVZqVSIZzeb84fYeDqn2TUdZAMaD17N+BTg4e2MrB3G8NoH5 sSCzuEu0XhteyuBHQlr8mPGEzKTImngfnMyluZrqD2KB2igF9sP55m2xMIMecEPhtuLA 4nVGQFMyeR1aE/q7n1DYHBj7/LzAA004RVWilYO8o8wT9bSrzdbsTTDNTg/jNQMn/qYW sUXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771666787; x=1772271587; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=r8HSfiLjyaGOvsXQk4UfGGYxPYIXKUkZDXPSFYlRGr0=; b=dJv+rGMccwyIsoSr3pMDcfS+XlSquO7ySXFKsCtVa27rDQwH2UhQvt1Y6dJHjwAMq+ vf5S1VhKBxg0Po4jB5G2ZYIqI6J6NYVtC6Yf7S9xid7jRDDbFP2Y1eVoI4E1urS2kJHT upEf2ReY/wmQ/89qBKCu7q5Reoe6Vwz1JyrF3Vk6oMdqdFRbsbX5Yco0q3w+jq07VDWx vMffZixaX1+g2+0QjAz2OORizPXN5uoGAuGasdb4FQwezCIQncGGz1PUZpNOq5Sy/Wjr fXwopK0ShxyoE4V6fxKsqtmbG74YZtBAl9VZcKjXe5rJJwOYbD6I6jlZCtK8fuVSXkMX CG9g== X-Forwarded-Encrypted: i=1; AJvYcCW/KEw/YkVUIoyl91/qKe9oydSkmFfJsJUzsSBRfuOifO458AZy5A4a7fBKZo3Pi1+2d6jDBRB6SF+Nse0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/esNdgrhgs1nLBQXrQw177TJCIInO3Vjlisxq1VKm84fso8pK wKI3ZH+aNWWZ4fyt3pLh0c8VGFvPnozhVivpNFt9jWiRMlb/iC3VxjTe X-Gm-Gg: AZuq6aJON/nx7qcoHCBP6jYFK7ZMg+8wAHSSv9XLaIJtX84yQM/hZjZFzXJa7aw9SxC s1o6F8TJ6mkKM6yR4ZAupY0HB4tFaRD3dstzlin4NxsxNWSCi69e6ziBddqb2ktcGrVRunCQaAp n9ySb43NoMVoseVCYVF5KnbMCuuhGZlr0Pwuk0ArRHkbooD5GNX6JkqNsRmQgsOdTwHyLN9Y2bi I5RQc6UYI4galTa6jiQBLBstQ+9ldX+mCZegW1jboVkGRI1XX/WFAroodjUjSHQRjX97MjkWecd Bfdfcjsd30I9Xjp2TKoGkknfOUbMHRKuhgwSmmnOw5RaqBnSQrd4fiqJeZjOixigCPGfgVogwRU f6+mQCAlm9V7HLJZEFXXTMJCCP52/Z/pv8y40gF0ECxExCRFmdSw1SKrtpe14GDEkC4IO7XK4LX v7jMNBD761liVGbtYmS7ZIrstJW9L0U4kwNmoktCsoFZ47 X-Received: by 2002:a05:6a00:2290:b0:81f:15b2:21ea with SMTP id d2e1a72fcca58-826daa310e7mr2286680b3a.42.1771666787132; Sat, 21 Feb 2026 01:39:47 -0800 (PST) Received: from localhost.localdomain ([49.79.21.101]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-826dd8ba11bsm1761708b3a.50.2026.02.21.01.39.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Feb 2026 01:39:46 -0800 (PST) From: Vernon Yang To: akpm@linux-foundation.org, david@kernel.org Cc: lorenzo.stoakes@oracle.com, ziy@nvidia.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vernon Yang Subject: [PATCH mm-new v8 0/4] Improve khugepaged scan logic Date: Sat, 21 Feb 2026 17:39:14 +0800 Message-ID: <20260221093918.1456187-1-vernon2gm@gmail.com> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Vernon Yang Hi all, This series is improve the khugepaged scan logic, reduce CPU consumption, prioritize scanning task that access memory frequently. The following data is traced by bpftrace[1] on a desktop system. After the system has been left idle for 10 minutes upon booting, a lot of SCAN_PMD_MAPPED or SCAN_NO_PTE_TABLE are observed during a full scan by khugepaged. @scan_pmd_status[1]: 1 ## SCAN_SUCCEED @scan_pmd_status[6]: 2 ## SCAN_EXCEED_SHARED_PTE @scan_pmd_status[3]: 142 ## SCAN_PMD_MAPPED @scan_pmd_status[2]: 178 ## SCAN_NO_PTE_TABLE total progress size: 674 MB Total time : 419 seconds ## include khugepaged_scan_sleep_millisecs The khugepaged has below phenomenon: the khugepaged list is scanned in a FIFO manner, as long as the task is not destroyed, 1. the task no longer has memory that can be collapsed into hugepage, continues scan it always. 2. the task at the front of the khugepaged scan list is cold, they are still scanned first. 3. everyone scan at intervals of khugepaged_scan_sleep_millisecs (default 10s). If we always scan the above two cases first, the valid scan will have to wait for a long time. For the first case, when the memory is either SCAN_PMD_MAPPED or SCAN_NO_PTE_TABLE or SCAN_PTE_MAPPED_HUGEPAGE [5], just skip it. For the second case, if the user has explicitly informed us via MADV_FREE that these folios will be freed, just skip it only. The below is some performance test results. kernbench results (testing on x86_64 machine): baseline w/o patches test w/ patches Amean user-32 18522.51 ( 0.00%) 18333.64 * 1.02%* Amean syst-32 1137.96 ( 0.00%) 1113.79 * 2.12%* Amean elsp-32 666.04 ( 0.00%) 659.44 * 0.99%* BAmean-95 user-32 18520.01 ( 0.00%) 18323.57 ( 1.06%) BAmean-95 syst-32 1137.68 ( 0.00%) 1110.50 ( 2.39%) BAmean-95 elsp-32 665.92 ( 0.00%) 659.06 ( 1.03%) BAmean-99 user-32 18520.01 ( 0.00%) 18323.57 ( 1.06%) BAmean-99 syst-32 1137.68 ( 0.00%) 1110.50 ( 2.39%) BAmean-99 elsp-32 665.92 ( 0.00%) 659.06 ( 1.03%) Create three task[2]: hot1 -> cold -> hot2. After all three task are created, each allocate memory 128MB. the hot1/hot2 task continuously access 128 MB memory, while the cold task only accesses its memory briefly andthen call madvise(MADV_FREE). Here are the performance test results: (Throughput bigger is better, other smaller is better) Testing on x86_64 machine: | task hot2 | without patch | with patch | delta | |---------------------|---------------|---------------|---------| | total accesses time | 3.14 sec | 2.93 sec | -6.69% | | cycles per access | 4.96 | 2.21 | -55.44% | | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% | | dTLB-load-misses | 284814532 | 69597236 | -75.56% | Testing on qemu-system-x86_64 -enable-kvm: | task hot2 | without patch | with patch | delta | |---------------------|---------------|---------------|---------| | total accesses time | 3.35 sec | 2.96 sec | -11.64% | | cycles per access | 7.29 | 2.07 | -71.60% | | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% | | dTLB-load-misses | 241600871 | 3216108 | -98.67% | This series is based on mm-new. Thank you very much for your comments and discussions. V7 -> V8: - Just not skip collapse for lazyfree folios in VM_DROPPABLE mappings. - "cur_progress" equal to 1 when SCAN_PTE_MAPPED_HUGEPAGE in file case. - V7 PATCH #5 has been merged into the mm-new branch. - Some cleaning, more detail commit log, and pickup Reviewed-by. V6 -> V7: - Use "*cur_progress += 1" at the beginning of the loop in anon case. - Always "cur_progress" equal to HPAGE_PMD_NR in file case. - Some cleaning, and pickup Acked-by and Reviewed-by. V5 -> V6: - Simplify hpage_collapse_scan_file() [3] and hpage_collapse_scan_pmd(). - Skip lazy-free folios in the khugepaged only [4]. - pickup Reviewed-by. V4 -> V5: - Patch #3 are squashed to Patch #2 - File patch utilize "xas->xa_index" to fix issue. - folio_is_lazyfree() to folio_test_lazyfree() - Just skip lazyfree folio simply. - Again test kernbench in the performance mode to improve stability. - pickup Acked-by and Reviewed-by. V3 -> V4: - Rebase on mm-new. - Make Patch #2 cleaner - Fix the lazyfree folio continue to be collapsed when skipped ahead. V2 -> V3: - Refine scan progress number, add folio_is_lazyfree helper - Fix warnings at SCAN_PTE_MAPPED_HUGEPAGE. - For MADV_FREE, we will skip the lazy-free folios instead. - For MADV_COLD, remove it. - Used hpage_collapse_test_exit_or_disable() instead of vma = NULL. - pickup Reviewed-by. V1 -> V2: - Rename full to full_scan_finished, pickup Acked-by. - Just skip SCAN_PMD_MAPPED/NO_PTE_TABLE memory, not remove mm. - Set VM_NOHUGEPAGE flag when MADV_COLD/MADV_FREE to just skip, not move mm. - Again test performance at the v6.19-rc2. V7 : https://lore.kernel.org/linux-mm/20260207081613.588598-1-vernon2gm@gmail.com V6 : https://lore.kernel.org/linux-mm/20260201122554.1470071-1-vernon2gm@gmail.com V5 : https://lore.kernel.org/linux-mm/20260123082232.16413-1-vernon2gm@gmail.com V4 : https://lore.kernel.org/linux-mm/20260111121909.8410-1-yanglincheng@kylinos.cn V3 : https://lore.kernel.org/linux-mm/20260104054112.4541-1-yanglincheng@kylinos.cn V2 : https://lore.kernel.org/linux-mm/20251229055151.54887-1-yanglincheng@kylinos.cn V1 : https://lore.kernel.org/linux-mm/20251215090419.174418-1-yanglincheng@kylinos.cn [1] https://github.com/vernon2gh/app_and_module/blob/main/khugepaged/khugepaged_mm.bt [2] https://github.com/vernon2gh/app_and_module/blob/main/khugepaged/app.c [3] https://lore.kernel.org/linux-mm/4c35391e-a944-4e62-9103-4a1c4961f62a@arm.com [4] https://lore.kernel.org/linux-mm/CACZaFFNY8+UKLzBGnmB3ij9amzBdKJgytcSNtA8fLCake8Ua=A@mail.gmail.com [5] https://lore.kernel.org/linux-mm/4qdu7owpmxfh3ugsue775fxarw5g2gcggbxdf5psj75nnu7z2u@cv2uu2yocaxq Vernon Yang (4): mm: khugepaged: add trace_mm_khugepaged_scan event mm: khugepaged: refine scan progress number mm: add folio_test_lazyfree helper mm: khugepaged: skip lazy-free folios include/linux/page-flags.h | 5 +++ include/trace/events/huge_memory.h | 26 ++++++++++++++ mm/khugepaged.c | 57 ++++++++++++++++++++++++------ mm/rmap.c | 2 +- mm/vmscan.c | 5 ++- 5 files changed, 81 insertions(+), 14 deletions(-) base-commit: a6fdc327de4678e54b5122441c970371014117b0 -- 2.51.0