From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 5FE893769F7 for ; Fri, 22 May 2026 14:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779461994; cv=none; b=ana3u5bzGMSWBl9NXN5AQb6mPYFxAOdIqEoUAHayebEwKQa33yxREaRIQy0SmGyAuYknVoTFl8J77hsUaT3NXXOM4XASx1U3U2U+SHYyB5r4d/qm7+O1wlijyRCxL9B/JPwu3nSiKC3Mq/14krBhFh+YfzVbHHCTyuSQBRleHDE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779461994; c=relaxed/simple; bh=yjEHj7Hu5eih+GutB0PtC1fAdyKISb7igDH92eZCkJ4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:content-type; b=gwLAxRR8fEr2EoqdWY9CvquKSsRxGwx7ChoGOPetN4N5IsZ7Ytwi9MP+2YljdrrYPwV/pBWqZ2OzzgyzdtjBfYp3EG0P8rmzOoCH0mSqfJnW7zAYmkZbYUAdRjr6n0hXh9DnNctPcX6L4063+64vETEnuqGPYPMz6G2MjxQQhgo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KZjJGxo7; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KZjJGxo7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779461991; 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: content-transfer-encoding:content-transfer-encoding; bh=cn0k/bwO5Qt8M+McWZ0EtdCuzV+0iQUlQzn/rjlgN8M=; b=KZjJGxo7vYVtI18/xmkRrMCGzF45XFLZF/s+yghmmQPC1rOuggtSnTK1cQ8fIcvgIjciVm s0KIH3RhHqbsAyWYrxZNJly64ohUSJTuPDxGLqe1eUfR3e8+lQ0YhYeE1ZLv4uToQoFnsW bIqil+6Rh9p64tRiLr8KCueUmqj7s2A= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-43-09seQE3CM-qkhp2s4IoU8w-1; Fri, 22 May 2026 10:59:48 -0400 X-MC-Unique: 09seQE3CM-qkhp2s4IoU8w-1 X-Mimecast-MFC-AGG-ID: 09seQE3CM-qkhp2s4IoU8w_1779461987 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1B81219560B2; Fri, 22 May 2026 14:59:47 +0000 (UTC) Received: from p1.redhat.com (unknown [10.44.24.8]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 699FF180034E; Fri, 22 May 2026 14:59:24 +0000 (UTC) From: Nico Pache To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Cc: aarcange@redhat.com, akpm@linux-foundation.org, anshuman.khandual@arm.com, apopple@nvidia.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, byungchul@sk.com, catalin.marinas@arm.com, cl@gentwo.org, corbet@lwn.net, dave.hansen@linux.intel.com, david@kernel.org, dev.jain@arm.com, gourry@gourry.net, hannes@cmpxchg.org, hughd@google.com, jack@suse.cz, jackmanb@google.com, jannh@google.com, jglisse@google.com, joshua.hahnjy@gmail.com, kas@kernel.org, lance.yang@linux.dev, liam@infradead.org, ljs@kernel.org, mathieu.desnoyers@efficios.com, matthew.brost@intel.com, mhiramat@kernel.org, mhocko@suse.com, npache@redhat.com, peterx@redhat.com, pfalcato@suse.de, rakie.kim@sk.com, raquini@redhat.com, rdunlap@infradead.org, richard.weiyang@gmail.com, rientjes@google.com, rostedt@goodmis.org, rppt@kernel.org, ryan.roberts@arm.com, shivankg@amd.com, sunnanyong@huawei.com, surenb@google.com, thomas.hellstrom@linux.intel.com, tiwai@suse.de, usamaarif642@gmail.com, vbabka@suse.cz, vishal.moola@gmail.com, wangkefeng.wang@huawei.com, will@kernel.org, willy@infradead.org, yang@os.amperecomputing.com, ying.huang@linux.alibaba.com, ziy@nvidia.com, zokeefe@google.com Subject: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP collapse support Date: Fri, 22 May 2026 08:59:55 -0600 Message-ID: <20260522150009.121603-1-npache@redhat.com> Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: tyK-FY4QpOTmx3VijXF6lTPIXjfscrto5cdLS6a9gTc_1779461987 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true The following series provides khugepaged with the capability to collapse anonymous memory regions to mTHPs. To achieve this we generalize the khugepaged functions to no longer depend on PMD_ORDER. Then during the PMD scan, we use a bitmap to track individual pages that are occupied (!none/zero). After the PMD scan is done, we use the bitmap to find the optimal mTHP sizes for the PMD range. The restriction on max_ptes_none is removed during the scan, to make sure we account for the whole PMD range in the bitmap. When no mTHP size is enabled, the legacy behavior of khugepaged is maintained. We currently only support max_ptes_none values of 0 or HPAGE_PMD_NR - 1 (ie 511). If any other value is specified, the kernel will emit a warning and mTHP collapse will default to max_ptes_none=0. If a mTHP collapse is attempted, but contains swapped out, or shared pages, we don't perform the collapse. It is now also possible to collapse to mTHPs without requiring the PMD THP size to be enabled. These limitations are to prevent collapse "creep" behavior. This prevents constantly promoting mTHPs to the next available size, which would occur because a collapse introduces more non-zero pages that would satisfy the promotion condition on subsequent scans. Patch 1-2: Generalize hugepage_vma_revalidate and alloc_charge_folio for arbitrary orders. Patch 3: Rework max_ptes_* handling into helper functions Patch 4: Generalize __collapse_huge_page_* for mTHP support Patch 5: Require collapse_huge_page to enter/exit with the lock dropped Patch 6: Generalize collapse_huge_page for mTHP collapse Patch 7: Skip collapsing mTHP to smaller orders Patch 8-9: Add per-order mTHP statistics and tracepoints Patch 10: Introduce collapse_allowable_orders helper function Patch 11-13: Introduce bitmap and mTHP collapse support, fully enabled Patch 14: Documentation Testing: - Built for x86_64, aarch64, ppc64le, and s390x - ran all arches on test suites provided by the kernel-tests project - internal testing suites: functional testing and performance testing - selftests mm - I created a test script that I used to push khugepaged to its limits while monitoring a number of stats and tracepoints. The code is available here[1] (Run in legacy mode for these changes and set mthp sizes to inherit) The summary from my testings was that there was no significant regression noticed through this test. In some cases my changes had better collapse latencies, and was able to scan more pages in the same amount of time/work, but for the most part the results were consistent. - redis testing. I did some testing with these changes along with my defer changes (see followup [2] post for more details). We've decided to get the mTHP changes merged first before attempting the defer series. - some basic testing on 64k page size. - lots of general use. [1] - https://gitlab.com/npache/khugepaged_mthp_test [2] - https://lore.kernel.org/lkml/20250515033857.132535-1-npache@redhat.com/ V18 Changes: - Added RBs/Acks - [patch 02] Guard count_memcg_folio_events with is_pmd_order() to keep THP_COLLAPSE_ALLOC PMD-only (Usama, Lance) - [patch 03] Convert C++ comments to C-style; fix "none-page" terminology to "empty PTEs or PTEs mapping the shared zeropage"; drop unnecessary userfaultfd comment; add const to local max_ptes_* variables; fix "repect" typo (Lance, David) - [patch 04] collapse_max_ptes_none() now returns 0 instead of -EINVAL for unsupported values; remove SCAN_INVALID_PTES_NONE; change return type from int to unsigned int and propagate to all callers; add comment above __collapse_huge_page_swapin explaining mTHP swap bail-out (David, Lorenzo, Lance, Wei Yang, Usama) - [patch 05] Rewrite collapse_huge_page lock comment to David's suggested wording (David) - [patch 11] Propagate unsigned int return type for max_ptes_none; remove the now-unnecessary negative return check (consequence of patch 04); Add optimization to the next_order goto that will prevent unnecessary iterations if there are no lower orders enabled (Vernon); update locking comment; pass VMA to mthp_collapse to improve uffd-armed detection, and prevent unnecessary work. (Wei) - [patch 14] Update documentation to reflect fallback-to-0 behavior V17: https://lore.kernel.org/all/20260511185817.686831-1-npache@redhat.com V16: https://lore.kernel.org/all/20260419185750.260784-1-npache@redhat.com V15: https://lore.kernel.org/all/20260226031741.230674-1-npache@redhat.com V14: https://lore.kernel.org/all/20260122192841.128719-1-npache@redhat.com V13: https://lore.kernel.org/all/20251201174627.23295-1-npache@redhat.com V12: https://lore.kernel.org/all/20251022183717.70829-1-npache@redhat.com V11: https://lore.kernel.org/all/20250912032810.197475-1-npache@redhat.com V10: https://lore.kernel.org/all/20250819134205.622806-1-npache@redhat.com V9 : https://lore.kernel.org/all/20250714003207.113275-1-npache@redhat.com V8 : https://lore.kernel.org/all/20250702055742.102808-1-npache@redhat.com V7 : https://lore.kernel.org/all/20250515032226.128900-1-npache@redhat.com V6 : https://lore.kernel.org/all/20250515030312.125567-1-npache@redhat.com V5 : https://lore.kernel.org/all/20250428181218.85925-1-npache@redhat.com V4 : https://lore.kernel.org/all/20250417000238.74567-1-npache@redhat.com V3 : https://lore.kernel.org/all/20250414220557.35388-1-npache@redhat.com V2 : https://lore.kernel.org/all/20250211003028.213461-1-npache@redhat.com V1 : https://lore.kernel.org/all/20250108233128.14484-1-npache@redhat.com Baolin Wang (1): mm/khugepaged: run khugepaged for all orders Dev Jain (1): mm/khugepaged: generalize alloc_charge_folio() Nico Pache (12): mm/khugepaged: generalize hugepage_vma_revalidate for mTHP support mm/khugepaged: rework max_ptes_* handling with helper functions mm/khugepaged: generalize __collapse_huge_page_* for mTHP support mm/khugepaged: require collapse_huge_page to enter/exit with the lock dropped mm/khugepaged: generalize collapse_huge_page for mTHP collapse mm/khugepaged: skip collapsing mTHP to smaller orders mm/khugepaged: add per-order mTHP collapse failure statistics mm/khugepaged: improve tracepoints for mTHP orders mm/khugepaged: introduce collapse_allowable_orders helper function mm/khugepaged: Introduce mTHP collapse support mm/khugepaged: avoid unnecessary mTHP collapse attempts Documentation: mm: update the admin guide for mTHP collapse Documentation/admin-guide/mm/transhuge.rst | 72 ++- include/linux/huge_mm.h | 5 + include/trace/events/huge_memory.h | 34 +- mm/huge_memory.c | 11 + mm/khugepaged.c | 634 ++++++++++++++++----- 5 files changed, 584 insertions(+), 172 deletions(-) base-commit: 6c8cb505a5634594b3ea159fd1c71bce2acf3346 -- 2.54.0