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

[Anshuman Khandual <anshuman.khandual@arm.com>]

On 18/09/25 1:24 AM, Luck, Tony wrote:
> On Wed, Sep 17, 2025 at 12:32:47PM -0700, Jiaqi Yan wrote:
>> +1. Given /proc/sys/vm/enable_soft_offline is extensible, I would
>> prefer a compact userspace API.
>>
>>> would create a new file, and the file has weird semantics such that it
>>> has no meaning when enable_soft_offline=0.
> 
> So the expand the bitmask idea from earlier in this thread?
> 
> Bit0	0 = soft offline disabled. 1 = Enabled (but see other bits)
> Bit1	0 = allow offline of 4K pages, 1 = suppress 4K offline
> Bit2	0 = allow offline of hugetlb, 1 = suppress hugetlb offline
> Bit3	0 = allow breakup of transparent huge pages to just offline 4K, 1 = suppress transparent breakup
> Bit4+	Reserved for suppressing other page types we invent in the future
> 
> Values 0 and 1 keep their original meaning.
> 
> Value 5 means: offline 4K, keep hugetlb, breakup transparent huge pages.

This disable bitmask (but when generally enabled via bit[0] = 1) method
seems much better. But I am not sure about page size being a valid page
type classification though. Just to start with, defining first two bits
in this bitmask should be good enough, which will atleast help document
and validate this new interface properly.

Bit1	0 = allow offline of hugetlb, 1 = suppress hugetlb offline
Bit2	0 = allow breakup of transparent huge pages to just offline base pages, 1 = suppress transparent breakup
Bit3+	Reserved for suppressing other page types we invent in the future