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

[John Hubbard]

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@xxxxxxxxxx> 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.


thanks,
-- 
John Hubbard