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

[David Hildenbrand <david@redhat.com>]

>>
>> 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" ?

-- 
Cheers,

David / dhildenb