Re: [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext)

[Tal Zussman <tz2294@columbia.edu>]

On 3/27/26 3:43 PM, Gregory Price wrote:
> On Fri, Mar 27, 2026 at 03:12:16PM -0400, Tal Zussman wrote:
>> 
>> It's been well-known in the academic realm for a while that there isn't
>> really a "one-size-fits-all" policy that works *best* for all workloads.
>> Yes, you can make a general policy that works *well*, but if you really care
>> about a workload's performance and want to squeeze out the last 10-20% (or
>> more) of performance, you need to be able to (1) experiment and (2) take
>> advantage of application-level insights. Being able to extend reclaim (in
>> our case with eBPF) enables that.
>>
> 
> This just makes me think going all the way to reclaim_ext and re-writing
> MGLRU as an eBPF extension in an effort to simplify the code/maintenance
> and keep what works working is the least-worst option.

That may very well be true, at least on the policy side. In fact, we
implemented an MGLRU policy in eBPF. The infrastructure side is a different
story, as Shakeel has pointed out.

> But this is a naive take, i'm sure making that interface stable would be
> even worse than just maintaining both LRU/MGLRU.

Putting eBPF aside for a second, I'm of the opinion that separating reclaim
policy from infrastructure and creating such an interface would actually be
beneficial for maintenance long-term. There's no clean separation between
policy and infrastructure right now, making the code less readable and
potentially affecting performance. I'm in the process of collecting some
instances of such overlap and assessing what their impact is.

Now, once you have such an interface... eBPF falls into place pretty
nicely...

Thanks,
Tal