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

[Baolin Wang]

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.