On Wed, Sep 17, 2025 at 2:39 PM Kyle Meyer kyle.meyer@hpe.com wrote:
On Wed, Sep 17, 2025 at 12:54:09PM -0700, 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.
Do you happen to have any use cases or reasoning for why someone might want to disable soft offline for 4K pages or transparent huge pages? I'd like to understand the motivation for adding the extra bits.
Not sure if making sense, but something I can think of are: one may really not want performance impact as THP will be split, THP and 4K pages will be migrated, and even wildly willing to defragment with 4K pages with corrected errors?
Thanks, Kyle Meyer