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

[Tal Zussman]

On 4/8/26 8:21 PM, 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@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.
> 

That's great to hear, thank you!

> 
> thanks,
> -- 
> John Hubbard
>