On 4/27/26 2:21 PM, David Hildenbrand (Arm) wrote: > On 4/19/26 20:57, Nico Pache wrote: >> Add three new mTHP statistics to track collapse failures for different >> orders when encountering swap PTEs, excessive none PTEs, and shared PTEs: >> >> - collapse_exceed_swap_pte: Increment when mTHP collapse fails due to swap >> PTEs >> >> - collapse_exceed_none_pte: Counts when mTHP collapse fails due to >> exceeding the none PTE threshold for the given order >> >> - collapse_exceed_shared_pte: Counts when mTHP collapse fails due to shared >> PTEs >> >> These statistics complement the existing THP_SCAN_EXCEED_* events by >> providing per-order granularity for mTHP collapse attempts. The stats are >> exposed via sysfs under >> `/sys/kernel/mm/transparent_hugepage/hugepages-*/stats/` for each >> supported hugepage size. >> >> As we currently dont support collapsing mTHPs that contain a swap or > > s/dont/do not/ > >> shared entry, those statistics keep track of how often we are >> encountering failed mTHP collapses due to these restrictions. >> >> Now that we plan to support mTHP collapse for anon pages, lets also track > > "We will add support for mTHP collapse for anonymous pages next; let's also > ..." > >> when this happens at the PMD level within the per-mTHP stats. > > What about file collapse? For example, we do adjust > count_vm_event(THP_SCAN_EXCEED_SWAP_PTE) and > count_vm_event(THP_SCAN_EXCEED_NONE_PTE) there. > > Wouldn't we want to update the HPAGE_PMD_ORDER side of things there already? > or > would we want to use a different counter for that?
Maybe? My thought process was that because we dont support mTHP in Shmem that those stats shouldnt be updated? not sure the right answer tbh-- hence why this comment says "now that.. for anon pages, lets track..". > >> >> Signed-off-by: Nico Pache <[email protected]> >> --- >> Documentation/admin-guide/mm/transhuge.rst | 24 ++++++++++++++++++++++ >> include/linux/huge_mm.h | 3 +++ >> mm/huge_memory.c | 7 +++++++ >> mm/khugepaged.c | 21 +++++++++++++++++-- >> 4 files changed, 53 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/admin-guide/mm/transhuge.rst >> b/Documentation/admin-guide/mm/transhuge.rst >> index c51932e6275d..eebb1f6bbc6c 100644 >> --- a/Documentation/admin-guide/mm/transhuge.rst >> +++ b/Documentation/admin-guide/mm/transhuge.rst >> @@ -714,6 +714,30 @@ nr_anon_partially_mapped >> an anonymous THP as "partially mapped" and count it here, even >> though it >> is not actually partially mapped anymore. >> >> +collapse_exceed_none_pte >> + The number of collapse attempts that failed due to exceeding the >> + max_ptes_none threshold. For mTHP collapse, Currently only >> max_ptes_none >> + values of 0 and (HPAGE_PMD_NR - 1) are supported. Any other value >> will >> + emit a warning and no mTHP collapse will be attempted. khugepaged >> will >> + try to collapse to the largest enabled (m)THP size; if it fails, it >> will >> + try the next lower enabled mTHP size. This counter records the >> number of >> + times a collapse attempt was skipped for exceeding the max_ptes_none >> + threshold, and khugepaged will move on to the next available mTHP >> size. > > Why is everything after the first sentence worth documenting here? This > doesn't > read like it belongs to a failure counter? > >> + >> +collapse_exceed_swap_pte >> + The number of anonymous mTHP PTE ranges which were unable to >> collapse due >> + to containing at least one swap PTE. Currently khugepaged does not >> + support collapsing mTHP regions that contain a swap PTE. This >> counter can >> + be used to monitor the number of khugepaged mTHP collapses that >> failed >> + due to the presence of a swap PTE. > > Can we similarly simplify that (and make it consistent with the one above) to > > "The number of collapse attempts that failed due to exceeding the > max_ptes_swap > threshold." > >> + >> +collapse_exceed_shared_pte >> + The number of anonymous mTHP PTE ranges which were unable to >> collapse due >> + to containing at least one shared PTE. Currently khugepaged does not >> + support collapsing mTHP PTE ranges that contain a shared PTE. This >> + counter can be used to monitor the number of khugepaged mTHP >> collapses >> + that failed due to the presence of a shared PTE. > > Same here > > "The number of collapse attempts that failed due to exceeding the > max_ptes_shared threshold." These all used to be very similar to what you have here. But Lorenzo asked me to expand all this (IIRC) several times. So here we are! I believe I even mentioned in the V15 that these are probably the "best" defined counters in the whole doc lol. Cheers, -- Nico > > ? > >> + > > [...] >
