From: Michal Hocko <mhocko@suse.com>
To: Jianyue Wu <wujianyue000@gmail.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
hannes@cmpxchg.org, david@kernel.org, zhengqi.arch@bytedance.com,
shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com,
chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com,
nphamcs@gmail.com, baohua@kernel.org, bhe@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: move folio LRU helpers out of swap
Date: Tue, 7 Apr 2026 14:46:54 +0200 [thread overview]
Message-ID: <adT8vnS27qKSTvOC@tiehlicka> (raw)
In-Reply-To: <CAJxJ_jjFonN8m1YsGh8FjMBbiociLiXzE=tS2+=Or4+PnTPr-g@mail.gmail.com>
On Tue 07-04-26 20:31:40, Jianyue Wu wrote:
> On 4/7/2026 7:20 PM, Michal Hocko wrote:
> >
> > All that big churn is really worth it? Are there any other reasons than
> > "not so appropriate"?
> >
> > Really if this is not a part of a much bigger plan then NAK.
>
> Hi Michal,
>
> The intent here is to keep generic LRU/reclaim helpers separate from
> swap-specific code paths.
OK, but why do we want this and cause a lot of code churn to achiev
that?
> The LRU helpers are shared by both file and anonymous memory, whereas
> swap.c is meant to host logic tied to swap devices and swap entries.
> Placing LRU code there would blur the boundary between general reclaim
> and swap, and make the code harder to follow.
The code is harder to follow than it could be, no questions about that.
But that alone is a rather weak argument to justify a lot of code move
that cause a lot of conflicts.
> Separately, I’ve been looking at routing zram’s swap-slot handling
> through swap-owned hooks (e.g., swap_ops / swapon probing), which would
> involve swapfile.c and swap.h. That’s likely orthogonal to this LRU
> move, but it’s driven by the same goal of clarifying the swap boundary.
Does that work benefits huge by this work?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2026-04-07 12:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 11:00 [PATCH] mm: move folio LRU helpers out of swap Jianyue Wu
2026-04-07 11:20 ` Michal Hocko
2026-04-07 12:31 ` Jianyue Wu
2026-04-07 12:46 ` Michal Hocko [this message]
2026-04-07 11:42 ` David Hildenbrand (Arm)
2026-04-07 12:33 ` Jianyue Wu
2026-04-07 13:40 ` Matthew Wilcox
2026-04-08 1:09 ` Barry Song
2026-04-07 14:22 ` Johannes Weiner
2026-04-08 0:41 ` Jianyue Wu
2026-04-08 2:27 ` Barry Song
2026-04-08 1:38 ` Baoquan He
2026-04-08 2:20 ` Barry Song
2026-04-08 2:49 ` Baoquan He
2026-04-08 14:50 ` Jianyue Wu
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=adT8vnS27qKSTvOC@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=nphamcs@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=wujianyue000@gmail.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.