[7.0][Feature] mm: add mTHP file folio fallback statistics · Pull Request !7627 · anolis/cloud-kernel

bugzilla: https://bugzilla.openanolis.cn/show_bug.cgi?id=36707

Commit b024a5c24839 ("anolis: mm: add mTHP counters for file folios") introduced MTHP_STAT_FILE_ALLOC to count successful file-backed large folio allocations in the readahead path. However when __filemap_get_folio_mpol() falls back to a lower order — either because the allocation failed or because filemap_add_folio() rejected the charge — no per-order counter is bumped. Operators cannot distinguish "no large folio attempted" from "tried order-N, fell back due to fragmentation or memcg charge limit".

This adds two new per-order counters mirroring the anon-folio triple (ANON_FAULT_FALLBACK / _CHARGE) and the shmem triple (SHMEM_FALLBACK / _CHARGE):

- MTHP_STAT_FILE_FALLBACK: alloc failure fallback
- MTHP_STAT_FILE_FALLBACK_CHARGE: filemap_add_folio failure fallback

Bumped at the two fallback sites in __filemap_get_folio_mpol() (mm/filemap.c), exposed via sysfs at /sys/kernel/mm/transparent_hugepage/hugepages-*kB/stats/file_fallback and file_fallback_charge.

Counter-only patch, zero behaviour change. +10 LoC across 3 files.

## Test

Built and booted on a single-node KVM ECS (7.0.0-gfa5d2c3ad926, CONFIG_TRANSPARENT_HUGEPAGE=y). Verified:

1. sysfs files present for every order (8kB..2048kB), initialized to 0.
2. Sequential read of a 256MB file (readahead path) drives file_alloc up by ~75 (mTHP active).
3. file_fallback stays 0 when buddy can satisfy 64kB allocs (correct: no fallback = no count).
4. Pattern matches existing MTHP_STAT_ANON_FAULT_FALLBACK (also 0 when no fragmentation).

Driving file_fallback > 0 requires severe external fragmentation that exhausts order-4 free pages (not achievable on a 3.7GB test box without OOM); on production hosts with real fragmentation this counter will light up.

类型	指派人员	状态
审查	zhongjiang winterddd xueshuai vxuyu baolin.wang	已完成 (0/0人)
测试	小龙	进行中 (0/1人)

GVPanolis/cloud-kernel

搜索帮助

GVP anolis/cloud-kernel