public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Axel Rasmussen <axelrasmussen@google.com>
Cc: Gregory Price <gourry@gourry.net>,
	"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, Tal Zussman <tz2294@columbia.edu>
Subject: Re: [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext)
Date: Fri, 27 Mar 2026 03:43:57 +0000	[thread overview]
Message-ID: <acX8_XMQYA0-NGUW@casper.infradead.org> (raw)
In-Reply-To: <CAJHvVciAmX9OFLBSahwvXL=E+3xnDsL2aE4WKfDBFqaT1Gu+Qg@mail.gmail.com>

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:
> >
> > On Thu, Mar 26, 2026 at 01:02:02PM -0700, Axel Rasmussen wrote:
> > >
> > > I think one thing we all agree on at least is, long term, there isn't
> > > really a good argument for having > 1 LRU implementation. E.g., we
> > > don't believe there are just irreconcilable differences, where one
> > > impl is better for some workloads, and another is better for others,
> > > and there is no way the two can be converged.
> > >
> >
> > I absolutely believe there are irreconcilable differences - but not in
> > the sense that one is better or worse, but in the sense that features
> > from one cannot work in the other.
> 
> Right, agreed. I mean a case where we have workloads A and B, such
> that there does not exist an implementation that can serve both well.
> If such workloads were "common" to me that would justify a reclaim_ops
> / pluggable abstraction layer. My thesis is that they are "not
> common", so I'm a bit skeptical the abstraction is worth it.

That isn't what Tal was telling me at Plumbers.  Adding him to cc so
he can dispute you in his own words, rather than my clumsy paraphrasing
of what he said.



  reply	other threads:[~2026-03-27  3:44 UTC|newest]

Thread overview: 35+ 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 [this message]
2026-03-27 19:12               ` Tal Zussman
2026-03-27 19:43                 ` Gregory Price
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-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=acX8_XMQYA0-NGUW@casper.infradead.org \
    --to=willy@infradead.org \
    --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=gourry@gourry.net \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox