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

[Yafang Shao <laoar.shao@gmail.com>]

On Tue, Jul 22, 2025 at 3:28 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 22.07.25 04:40, Yafang Shao wrote:
> > On Sun, Jul 20, 2025 at 11:56 PM David Hildenbrand <david@redhat.com> wrote:
> >>
> >>>>
> >>>> We discussed this yesterday at a THP upstream meeting, and what we
> >>>> should look into is:
> >>>>
> >>>> (1) Having a callback like
> >>>>
> >>>> unsigned int (*get_suggested_order)(.., bool in_pagefault);
> >>>
> >>> This interface meets our needs precisely, enabling allocation orders
> >>> of either 0 or 9 as required by our workloads.
> >>>
> >>>>
> >>>> Where we can provide some information about the fault (vma
> >>>> size/flags/anon_name), and whether we are in the page fault (or in
> >>>> khugepaged).
> >>>>
> >>>> Maybe we want a bitmap of orders to try (fallback), not sure yet.
> >>>>
> >>>> (2) Having some way to tag these callbacks as "this is absolutely
> >>>> unstable for now and can be changed as we please.".
> >>>
> >>> BPF has already helped us complete this, so we don’t need to implement
> >>> this restriction.
> >>> Note that all BPF kfuncs (including struct_ops) are currently unstable
> >>> and may change in the future.
> >>   > > Alexei, could you confirm this understanding?
> >>
> >> Every MM person I talked to about this was like "as soon as it's
> >> actively used out there (e.g., a distro supports it), there is no way
> >> you can easily change these callbacks ever again - it will just silently
> >> become stable."
> >>
> >> That is actually the biggest concern from the MM side: being stuck with
> >> an interface that was promised to be "unstable" but suddenly it's
> >> not-so-unstable anymore, and we have to support something that is very
> >> likely to be changed in the future.
> >>
> >> Which guarantees do we have in the regard?
> >>
> >> How can we make it clear to anybody using this specific interface that
> >> "if you depend on this being stable, you should learn how to read and
> >> you are to blame, not the MM people" ?
> >
> > As explained in the kernel document [0]:
> >
> > kfuncs provide a kernel <-> kernel API, and thus are not bound by any
> > of the strict stability restrictions associated with kernel <-> user
> > UAPIs. This means they can be thought of as similar to
> > EXPORT_SYMBOL_GPL, and can therefore be modified or removed by a
> > maintainer of the subsystem they’re defined in when it’s deemed
> > necessary.
> >
> > [0] https://docs.kernel.org/bpf/kfuncs.html#bpf-kfunc-lifecycle-expectations
> >
> > That said, users of BPF kfuncs should treat them as inherently
> > unstable and take responsibility for verifying their compatibility
> > when switching kernel versions. However, this does not imply that BPF
> > kfuncs can be modified arbitrarily.
> >
> > For widely adopted kfuncs that deliver substantial value, changes
> > should be made cautiously—preferably through backward-compatible
> > extensions to ensure continued functionality across new kernel
> > versions. Removal should only be considered in exceptional cases, such
> > as:
> > - Severe, unfixable issues within the kernel
> > - Maintenance burdens that block new features or critical improvements.
>
> And that is exactly what we are worried about.
>
> You don't know beforehand whether something will be "widely adopted".
>
> Even if there is the "A kfunc will never have any hard stability
> guarantees." in there.
>
> The concerning bit is:
>
> "kfuncs that are widely used or have been in the kernel for a long time
> will be more difficult to justify being changed or removed by a
> maintainer. "
>
> Just no. Not going to happen for the kfuncs we know upfront (like here)
> will stand in our way in the future at some point and *will* be changed
> one way or another.
>
>
> So for these kfuncs I want a clear way of expressing "whatever the
> kfuncs doc says, this here is completely unstable even if widely used"

This statement does not conflict with the BPF kfuncs documentation, as
it explicitly states:
"This means they can be thought of as similar to EXPORT_SYMBOL_GPL,
and can therefore be modified or removed by a maintainer of the
subsystem they're defined in when deemed necessary."

There is no question that subsystem maintainers have the authority to
remove kfuncs. However, the reason I raised the issue of removing
widely used kfuncs is to highlight the recommended practice:
- First mark the kfunc as KF_DEPRECATED.
- Remove it in the next development cycle.

While this is not a strict requirement—maintainers can remove kfuncs
immediately without deprecation—following this guideline helps avoid
unnecessary disruptions for users.

-- 
Regards
Yafang