Messages in this thread |  | | Date | Mon, 27 Apr 2026 22:21:08 +0200 | | Subject | Re: [PATCH 7.2 v16 07/13] mm/khugepaged: add per-order mTHP collapse failure statistics | | From | "David Hildenbrand (Arm)" <> |
| |
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 <npache@redhat.com> > --- > 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
|  |