Re: [PATCH v10 00/13] khugepaged: mTHP support
From: David Hildenbrand <hidden>
Date: 2025-09-01 16:46:56
Also in:
linux-doc, linux-mm, lkml
On 29.08.25 03:55, Baolin Wang wrote:
On 2025/8/28 18:48, Dev Jain wrote:quoted
On 28/08/25 3:16 pm, Baolin Wang wrote:quoted
(Sorry for chiming in late) On 2025/8/22 22:10, David Hildenbrand wrote:quoted
quoted
quoted
Once could also easily support the value 255 (HPAGE_PMD_NR / 2- 1), but not sure if we have to add that for now.Yeah not so sure about this, this is a 'just have to know' too, and yes you might add it to the docs, but people are going to be mightily confused, esp if it's a calculated value. I don't see any other way around having a separate tunable if we don't just have something VERY simple like on/off.Yeah, not advocating that we add support for other values than 0/511, really.quoted
Also the mentioned issue sounds like something that needs to be fixed elsewhere honestly in the algorithm used to figure out mTHP ranges (I may be wrong - and happy to stand corrected if this is somehow inherent, but reallly feels that way).I think the creep is unavoidable for certain values. If you have the first two pages of a PMD area populated, and you allow for at least half of the #PTEs to be non/zero, you'd collapse first a order-2 folio, then and order-3 ... until you reached PMD order. So for now we really should just support 0 / 511 to say "don't collapse if there are holes" vs. "always collapse if there is at least one pte used".If we only allow setting 0 or 511, as Nico mentioned before, "At 511, no mTHP collapses would ever occur anyway, unless you have 2MB disabled and other mTHP sizes enabled. Technically, at 511, only the highest enabled order would ever be collapsed."I didn't understand this statement. At 511, mTHP collapses will occur if khugepaged cannot get a PMD folio. Our goal is to collapse to the highest order folio.Yes, I’m not saying that it’s incorrect behavior when set to 511. What I mean is, as in the example I gave below, users may only want to allow a large order collapse when the number of present PTEs reaches half of the large folio, in order to avoid RSS bloat.
How do these users control allocation at fault time where this parameter is completely ignored? -- Cheers David / dhildenb