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

[Lorenzo Stoakes <ljs@kernel.org>]

On Wed, Apr 08, 2026 at 05:21:17PM -0700, John Hubbard wrote:
> On 3/27/26 12:12 PM, Tal Zussman wrote:
> > On 3/26/26 11:43 PM, Matthew Wilcox wrote:
> >> On Thu, Mar 26, 2026 at 01:47:43PM -0700, Axel Rasmussen wrote:
> >>> On Thu, Mar 26, 2026 at 1:30 PM Gregory Price <gourry@gourry.net> wrote:
> ...
> > Yeah, unfortunately it's not so straightforward. As a simple illustrative
> > example, consider a file-search workload, where you search through a large
> > number of files over and over again (e.g., a poor kernel developer trying to
> > understand how the page cache works). This follows an MRU, rather than LRU,
> > pattern, and readahead doesn't help much, leading the active/inactive and
> > MGLRU policies to have similar performance (~40s runtime in a specific
> > benchmark we ran). In comparison, using cache_ext (our eBPF-based caching
> > framework), we can run an MRU policy and it goes down to 20s.
>
> That's dramatic!
>
> ...
> > 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.
>
> I think that that point has been less clear, outside of academia. In fact,
> MGRLU (to the extent that we believed we would eventually get rid of LRU,
> in favor of MGLRU) doubled down on the idea of one size fits all. So this
> is interesting.
>
> > 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.
> >
> > We wrote a paper about this that was published a few months ago [1]. Happy
> > to answer any questions and continue the discussion!
> >
> > [1] https://dl.acm.org/doi/pdf/10.1145/3731569.3764820
> >
>
> Excellent work, I was delighted to find a well-balanced description of
> both older and more recent history of the Linux page cache there.
>
> It's helpful to read this, even if we go with a non-eBPF approach.

Yes, thanks for that, it's interesting!

But I would say for now we need to defer any consideration of bpf being a
thing until we actually get things into shape in terms of improving and
modularising the existing reclaim mechanisms.

mm has been far too keen to take features without paying down technical
debt first and it's been very costly, so before anything else, we must
ensure that reclaim is both long-term maintainable and maintained.

In terms of reclaim bpf as a concept in general - reclaim is so very
sensitive to even minor changes, and I fear that people might find
something that appears to dramatically improve matters in one scenario, but
end up with an unusable system in another.

A bad sched_ext implementation might result in poor responsiveness, but a
bad reclaim_ext implementation might result in a soft-locked system, and I
fear that it might be quite easy to do that.

In any case, we can look at all that once we are in a better place with
reclaim, which Shakeel's proposal focuses on and I'm very much in favour
of! :)

>
>
> thanks,
> --
> John Hubbard
>

Cheers, Lorenzo