From: Gregory Price <gourry@gourry.net>
To: Tal Zussman <tz2294@columbia.edu>
Cc: Matthew Wilcox <willy@infradead.org>,
Axel Rasmussen <axelrasmussen@google.com>,
"Lorenzo Stoakes (Oracle)" <ljs@kernel.org>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
lsf-pc@lists.linux-foundation.org,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Chen Ridong <chenridong@huaweicloud.com>,
Emil Tsalapatis <emil@etsalapatis.com>,
Alexei Starovoitov <ast@kernel.org>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Kairui Song <ryncsn@gmail.com>, Nhat Pham <nphamcs@gmail.com>,
Barry Song <21cnbao@gmail.com>,
David Stevens <stevensd@google.com>,
Vernon Yang <vernon2gm@gmail.com>,
David Rientjes <rientjes@google.com>,
Kalesh Singh <kaleshsingh@google.com>,
wangzicheng <wangzicheng@honor.com>,
"T . J . Mercier" <tjmercier@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Suren Baghdasaryan <surenb@google.com>,
Meta kernel team <kernel-team@meta.com>,
bpf@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext)
Date: Fri, 27 Mar 2026 14:43:34 -0500 [thread overview]
Message-ID: <acbd5lKEh8xa1IQk@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <6f40c513-af3e-45b6-9000-c61494a23bd3@columbia.edu>
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.
But this is a naive take, i'm sure making that interface stable would be
even worse than just maintaining both LRU/MGLRU.
~Gregory
next prev parent reply other threads:[~2026-03-27 19:43 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 21:06 [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext) Shakeel Butt
2026-03-26 0:10 ` T.J. Mercier
2026-03-26 2:05 ` Andrew Morton
2026-03-26 7:03 ` Michal Hocko
2026-03-26 8:02 ` Lorenzo Stoakes (Oracle)
2026-03-26 12:37 ` Kairui Song
2026-03-26 13:13 ` Lorenzo Stoakes (Oracle)
2026-03-26 13:42 ` David Hildenbrand (Arm)
2026-03-26 13:45 ` Lorenzo Stoakes (Oracle)
2026-03-26 16:02 ` Lorenzo Stoakes (Oracle)
2026-03-26 20:02 ` Axel Rasmussen
2026-03-26 20:30 ` Gregory Price
2026-03-26 20:47 ` Axel Rasmussen
2026-03-27 3:43 ` Matthew Wilcox
2026-03-27 19:12 ` Tal Zussman
2026-03-27 19:43 ` Gregory Price [this message]
2026-04-14 21:11 ` Tal Zussman
2026-04-09 0:21 ` John Hubbard
2026-04-09 8:22 ` Lorenzo Stoakes
2026-04-14 21:38 ` Tal Zussman
2026-04-14 20:35 ` Tal Zussman
2026-03-27 8:07 ` [Lsf-pc] " Vlastimil Babka
2026-03-27 9:29 ` Lorenzo Stoakes (Oracle)
2026-03-26 12:06 ` Kairui Song
2026-03-26 12:31 ` Lorenzo Stoakes (Oracle)
2026-03-26 13:17 ` Kairui Song
2026-03-26 13:26 ` Lorenzo Stoakes (Oracle)
2026-03-26 13:21 ` Shakeel Butt
2026-03-26 7:12 ` Michal Hocko
2026-03-26 13:44 ` Shakeel Butt
2026-03-26 15:24 ` Michal Hocko
2026-03-26 18:21 ` Shakeel Butt
2026-03-26 7:18 ` wangzicheng
2026-03-26 11:43 ` Lorenzo Stoakes (Oracle)
2026-03-26 15:24 ` Gregory Price
2026-03-26 15:35 ` Lorenzo Stoakes (Oracle)
2026-03-26 16:32 ` Gregory Price
2026-03-26 16:40 ` Lorenzo Stoakes (Oracle)
2026-03-27 19:53 ` Johannes Weiner
2026-04-07 11:36 ` Lorenzo Stoakes
2026-04-07 16:56 ` Gregory Price
2026-04-07 17:30 ` Lorenzo Stoakes
2026-04-07 17:52 ` Johannes Weiner
2026-04-07 18:37 ` Gregory Price
2026-04-08 6:48 ` Lorenzo Stoakes
2026-03-26 18:49 ` Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acbd5lKEh8xa1IQk@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=axelrasmussen@google.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=bpf@vger.kernel.org \
--cc=chenridong@huaweicloud.com \
--cc=david@kernel.org \
--cc=emil@etsalapatis.com \
--cc=hannes@cmpxchg.org \
--cc=kaleshsingh@google.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.com \
--cc=nphamcs@gmail.com \
--cc=rientjes@google.com \
--cc=ryncsn@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=stevensd@google.com \
--cc=surenb@google.com \
--cc=tjmercier@google.com \
--cc=tz2294@columbia.edu \
--cc=vernon2gm@gmail.com \
--cc=wangzicheng@honor.com \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.