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/[email protected]
If you think this should be handled differently, I'm open to suggestions.
Thanks for the feedback,
Kyle Meyer
