Re: [RFC PATCH v3 0/5] mm, bpf: BPF based THP adjustment

[David Hildenbrand <david@redhat.com>]

On 08.06.25 09:35, Yafang Shao wrote:

Sorry for not replying earlier, I was caught up with all other stuff.

I still consider this a very interesting approach, although I think we 
should think more about what a reasonable policy would look like 
medoium-term (in particular, multiple THP sizes, not always falling back 
to small pages if it means splitting excessively in the buddy etc.)

> Background
> ----------
> 
> We have consistently configured THP to "never" on our production servers
> due to past incidents caused by its behavior:
> 
> - Increased memory consumption
>    THP significantly raises overall memory usage.
> 
> - Latency spikes
>    Random latency spikes occur due to more frequent memory compaction
>    activity triggered by THP.
> 
> - Lack of Fine-Grained Control
>    THP tuning knobs are globally configured, making them unsuitable for
>    containerized environments. When different workloads run on the same
>    host, enabling THP globally (without per-workload control) can cause
>    unpredictable behavior.
> 
> Due to these issues, system administrators remain hesitant to switch to
> "madvise" or "always" modes—unless finer-grained control over THP
> behavior is implemented.
> 
> New Motivation
> --------------
> 
> We have now identified that certain AI workloads achieve substantial
> performance gains with THP enabled. However, we’ve also verified that some
> workloads see little to no benefit—or are even negatively impacted—by THP.
> 
> In our Kubernetes environment, we deploy mixed workloads on a single server
> to maximize resource utilization. Our goal is to selectively enable THP for
> services that benefit from it while keeping it disabled for others. This
> approach allows us to incrementally enable THP for additional services and
> assess how to make it more viable in production.
> 
> Proposed Solution
> -----------------
> 
> To enable fine-grained control over THP behavior, we propose dynamically
> adjusting THP policies using BPF. This approach allows per-workload THP
> tuning, providing greater flexibility and precision.
> 
> The BPF-based THP adjustment mechanism introduces two new APIs for granular
> policy control:
> 
> - THP allocator
> 
>    int (*allocator)(unsigned long vm_flags, unsigned long tva_flags);
> 
>    The BPF program returns either THP_ALLOC_CURRENT or THP_ALLOC_KHUGEPAGED,
>    indicating whether THP allocation should be performed synchronously
>    (current task) or asynchronously (khugepaged).
> 
>    The decision is based on the current task context, VMA flags, and TVA
>    flags.

I think we should go one step further and actually get advises about the 
orders (THP sizes) to use. It might be helpful if the program would have 
access to system stats, to make an educated decision.

Given page fault information and system information, the program could 
then decide which orders to try to allocate.

That means, one would query during page faults and during khugepaged, 
which order one should try -- compared to our current approach of "start 
with the largest order that is enabled and fits".

> 
> - THP reclaimer
> 
>    int (*reclaimer)(bool vma_madvised);
> 
>    The BPF program returns either RECLAIMER_CURRENT or RECLAIMER_KSWAPD,
>    determining whether memory reclamation is handled by the current task or
>    kswapd.

Not sure about that, will have to look into the details.

But what could be interesting is deciding how to deal with underutilized 
THPs: for now we will try replacing zero-filled pages by the shared 
zeropage during a split. *maybe* some workloads could benefit from ... 
not doing that, and instead optimize the split.

Will maybe be a bit more trick, though.


-- 
Cheers,

David / dhildenb