Re: [PATCH 7.2 v2 05/12] mm/khugepaged: remove READ_ONLY_THP_FOR_FS check in hugepage_pmd_enabled()

Baolin Wang
2026-04-15T09:22:08Z

On 4/15/26 4:00 PM, David Hildenbrand (Arm) wrote:
> On 4/15/26 08:36, Baolin Wang wrote:
>>
>>
>> On 4/15/26 2:25 AM, Zi Yan wrote:
>>> On 14 Apr 2026, at 14:14, David Hildenbrand (Arm) wrote:
>>>
>>>>
>>>> Yeah, it would be better if we could avoid it. But the dependency on the
>>>> global toggle as it is today is a bit weird.
>>>>
>>>>
>>>> I don't think there is other interaction with FS and the global toggle
>>>> besides this and the one you are adjusting, right?
>>>>
>>
>> I'm afraid not. Please also consider the per-size mTHP interfaces. It's
>> possible that hugepage_global_enabled() returns false, but
>> hugepages-2048kB/enabled is set to "always", which would still allow
>> khugepaged to collapse folios.

My comments are in reply to Zi’s comment:

"I think hugepage_global_enabled() should be enough to decide whether
khugepaged should run or not. "

I’m concerned that only relying on hugepage_global_enabled() to decide
whether khugepaged should run would cause a regression for anonymous and
shmem memory collapse, as it ignores per-size mTHP configuration.

> The question is really which semantics we want.
>
> Right now, there is no way to disable khugepaged for anon pages, to just
> get them during page faults.

Right.

> And we are now talking about the same problem for FS: to only get them
> during page faults (like we did so far without CONFIG_READ_ONLY_THP_FOR_FS).

OK. I’m fine with using hugepage_global_enabled() to determine whether
khugepaged scans file folios.

My concern is that for anonymous memory and shmem, the per-size mTHP
settings should be considered.