From: Lorenzo Stoakes <ljs@kernel.org>
To: Jianyue Wu <wujianyue000@gmail.com>
Cc: Baoquan He <baoquan.he@linux.dev>,
Matthew Wilcox <willy@infradead.org>,
Tal Zussman <tz2294@columbia.edu>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <bhe@redhat.com>,
Barry Song <baohua@kernel.org>,
Youngjun Park <youngjun.park@lge.com>,
Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] mm: move folio LRU code out of swap
Date: Wed, 3 Jun 2026 13:40:51 +0100 [thread overview]
Message-ID: <aiAgvcS7b19G0wEu@lucifer> (raw)
In-Reply-To: <CAJxJ_jhTAS3gbo5AoLPGCUSchUPTsUVzkNVprg9pfzqXFpPEaA@mail.gmail.com>
On Wed, Jun 03, 2026 at 08:29:44PM +0800, Jianyue Wu wrote:
> On Wed, Jun 3, 2026 at 8:03 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Wed, Jun 03, 2026 at 06:49:16PM +0800, Baoquan He wrote:
> > > On 06/02/26 at 04:57pm, Matthew Wilcox wrote:
> > > > On Tue, Jun 02, 2026 at 09:01:16AM +0800, Jianyue Wu wrote:
> > > > > Rename mm/swap.c to mm/folio_lru.c so the filename better matches
> > > > > the code's main responsibility.
> > > > >
> > > > > This keeps the implementation split from swap-specific code without
> > > > > changing the published LRU helper interfaces.
> > > >
> > > > At the same time, we have Tal trying to split folio_wait.c out
> > > > of filemap.c. https://lore.kernel.org/linux-mm/20260520-filemap-split-v1-0-c36ddc2b6cf2@columbia.edu/
> > > >
> > > > I wonder if instead of folio_lru.c and folio_wait.c, we shouldn't simply
> > > > have folio.c. Tal has 700 lines in his diffstat, you'll have about 1100
> > > > lines, so that's about 1800 llines which seems like a good size.
> > > > There's some functions from mm/util.c that would fit nicely too --
> > > > folio_mapping(), folio_anon_vma(), folio_copy(), flush_dcache_folio()
> > >
> > > I think folio_lru.c and folio_wait.c are better than a single folio.c.
> > >
> > > A single folio.c with all of them would have no clear boundary for what
> > > belongs there and what doesn't. For comparison, page_alloc.c isn't called
> > > page.c (we have files called mm/page*.c).
> >
> > Well page_alloc.c doesn't only contain things that operate on struct page *
> > right?
> >
> > Whereas folio.c is strictly operations literally performed on folios which seems
> > like a good match to me.
> >
> > I find folio_lru.c and folio_wait.c far more difficult to figure out what goes
> > where and there'll be a bunch of miscellaneous stuff all over the place.
> >
> > I vote for folio.c.
> >
> > >
> > > >
> > > > Other people have thoughts?
> > > >
> >
> > Thanks, Lorenzo
>
> Thanks Matthew, Baoquan and Lorenzo for the naming discussion.
>
> I'm posting v4 shortly. It keeps the rename to mm/folio_lru.c so this
> series stays a small cleanup on top of the swap_ops work. A broader
> mm/folio.c (together with Tal's folio_wait split and the util.c
> helpers Matthew mentioned) will be a separate follow-up
> once there is maintainer consensus on the file boundaries.
Agreed! :) Let's get this in first.
>
> Happy to help on that follow-up.
Thanks!
>
> Thanks,
> Best regards,
> Jianyue
Cheers, Lorenzo
next prev parent reply other threads:[~2026-06-03 12:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 1:01 [PATCH v3 0/3] mm: clean up folio LRU and swap declarations Jianyue Wu
2026-06-02 1:01 ` [PATCH v3 1/3] mm/swap: colocate page-cluster sysctl with swap readahead Jianyue Wu
2026-06-02 1:01 ` [PATCH v3 2/3] mm: move folio LRU code out of swap Jianyue Wu
2026-06-02 11:28 ` Baoquan He
2026-06-02 13:38 ` Jianyue Wu
2026-06-02 15:57 ` Matthew Wilcox
2026-06-03 10:49 ` Baoquan He
2026-06-03 12:03 ` Lorenzo Stoakes
2026-06-03 12:29 ` Jianyue Wu
2026-06-03 12:40 ` Lorenzo Stoakes [this message]
2026-06-03 15:39 ` Matthew Wilcox
2026-06-04 2:35 ` Jianyue Wu
2026-06-03 15:10 ` Baoquan He
2026-06-03 12:43 ` Lorenzo Stoakes
2026-06-02 1:01 ` [PATCH v3 3/3] mm: move reclaim-internal declarations out of swap.h 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=aiAgvcS7b19G0wEu@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kasong@tencent.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=nphamcs@gmail.com \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=tz2294@columbia.edu \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=wujianyue000@gmail.com \
--cc=youngjun.park@lge.com \
--cc=yuanchu@google.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.