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? > > 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." ? > + [...] -- Cheers, David
