Re: [PATCH v3] mm/memory-failure: Support disabling soft offline for HugeTLB pages

[Kyle Meyer <kyle.meyer@hpe.com>]

On Tue, Sep 15, 2026 at 10:31:42AM +0200, Michal Hocko wrote:
> On Mon 14-09-26 18:49:38, Kyle Meyer wrote:
> > Soft offlining a HugeTLB page dissolves it, permanently reducing the
> > HugeTLB page pool. This can be problematic for workloads that depend on
> > a fixed number of HugeTLB pages.
> > 
> > Currently, soft offline must be disabled to prevent HugeTLB pages from
> > being soft offlined.
> > 
> > This patch allows soft offline to be disabled for HugeTLB pages while
> > remaining enabled for non-HugeTLB pages.
> > 
> > Commit 56374430c5dfc ("mm/memory-failure: userspace controls
> > soft-offlining pages") introduced the following sysctl interface to
> > control soft offline:
> > 
> > /proc/sys/vm/enable_soft_offline
> > 
> > The interface does not distinguish between page types:
> > 
> >     0 - Soft offline is disabled
> >     1 - Soft offline is enabled
> > 
> > Convert enable_soft_offline to a bitmask and support disabling soft
> > offline for HugeTLB pages:
> > 
> > Bits:
> > 
> >     0 - Enable soft offline
> >     1 - Disable soft offline for HugeTLB pages
> > 
> > Supported values:
> > 
> >     0 - Soft offline is disabled
> >     1 - Soft offline is enabled
> >     3 - Soft offline is enabled (disabled for HugeTLB pages)
> > 
> > Existing behavior is preserved.
> > 
> > Update documentation and HugeTLB soft offline selftests.
> 
> This is adding a lot of user interfaces to control something you can
> disable by config option for an admin only functionality.

I may be missing it, but I'm not aware of a config option that disables soft
offline specifically for HugeTLB pages.

> I fail to to see any actual justification for all of that. If an admin
> can disolve a hugetlb page it has power to allocate a new one as well.

Allocating HugeTLB pages after boot is not guaranteed.

> Not to menation that the whole soft offlining is mostly a testing
> feature so adding a lot of fine grained configuration space seems
> excessive to me.

Can you elaborate on "mostly a testing feature"? For example, how does that
apply to the BIOS/GHES path discussed here?

https://lore.kernel.org/all/aMkOCmGBhZKhKPrI@hpe.com

If you think this should be handled differently, I'm open to suggestions.

Thanks for the feedback,
Kyle Meyer