From: Shakeel Butt <shakeel.butt@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kairui Song <ryncsn@gmail.com>,
linux-mm@kvack.org, 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>,
Lorenzo Stoakes <ljs@kernel.org>, Barry Song <baohua@kernel.org>,
David Stevens <stevensd@google.com>,
Chen Ridong <chenridong@huaweicloud.com>,
Leno Hou <lenohou@gmail.com>, Yafang Shao <laoar.shao@gmail.com>,
Yu Zhao <yuzhao@google.com>,
Zicheng Wang <wangzicheng@honor.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Kalesh Singh <kaleshsingh@google.com>,
Suren Baghdasaryan <surenb@google.com>,
Chris Li <chrisl@kernel.org>, Vernon Yang <vernon2gm@gmail.com>,
linux-kernel@vger.kernel.org, Qi Zheng <qi.zheng@linux.dev>
Subject: Re: [PATCH v7 00/15] mm/mglru: improve reclaim loop and dirty folio handling
Date: Tue, 26 May 2026 20:25:39 -0700 [thread overview]
Message-ID: <ahZjvYs83591EYXW@linux.dev> (raw)
In-Reply-To: <20260526183506.ffb1bbe41043c6247557caa1@linux-foundation.org>
On Tue, May 26, 2026 at 06:35:06PM -0700, Andrew Morton wrote:
> On Mon, 11 May 2026 22:56:21 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> > > > Please include traditional LRU results for all of the following experiments as
> > > > well (where it makes sense).
> > >
> > > Sure, I've spawn a few test instances, was busy travelling last week.
> > > That specific test machine is occupied so it might take a while.
> > >
> > > A systematic test run takes roughly one or two days to complete for
> > > one kernel version or config, e.g. the JS test takes at least 2 hours
> > > to finish. Comparing versions/setups takes more time.
> > >
> >
> > No worries, we have couple of weeks before the next merge window, so no urgency.
>
> Well, no, not really. Some schmuck wants to get our
> stable-non-rebasing branch into upstreamable shape well before the next
> merge window.
>
> This series was issued a month ago!
>
> Sorry to crack the whip, but let's please all be aware or our
> upstreaming timing.
Thanks for the reminder.
>
> > I will go through the series in depth, hopefully there will not be a need for
> > next version and in that case, please just resend the cover letter with the
> > information you provided below and don't worry about the length of the cover
> > letter.
>
> That's a plan.
>
> Happily, MGRLU changes are well-isolated so I was able to trivially
> move this series to the tail of mm-unstable.
>
> It isn't a problem at all for me to defer this until the next cycle -
> please let me know.
I am on it and will aim to be done by weekend.
>
> I'd like to know this as early as possible so I can hide the series
> until after -rc1. We shouldn't have "not for next merge window"
> material in there possibly invalidating our ongoing testing.
Ack.
next prev parent reply other threads:[~2026-05-27 3:26 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 18:06 [PATCH v7 00/15] mm/mglru: improve reclaim loop and dirty folio handling Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 01/15] mm/mglru: consolidate common code for retrieving evictable size Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-05-29 5:36 ` Shakeel Butt
2026-04-27 18:06 ` [PATCH v7 02/15] mm/mglru: rename variables related to aging and rotation Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-05-29 5:37 ` Shakeel Butt
2026-04-27 18:06 ` [PATCH v7 03/15] mm/mglru: relocate the LRU scan batch limit to callers Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-05-29 5:40 ` Shakeel Butt
2026-05-29 6:01 ` Kairui Song
2026-05-29 21:29 ` Shakeel Butt
2026-04-27 18:06 ` [PATCH v7 04/15] mm/mglru: restructure the reclaim loop Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-05-30 5:48 ` Shakeel Butt
2026-04-27 18:06 ` [PATCH v7 05/15] mm/mglru: scan and count the exact number of folios Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 06/15] mm/mglru: avoid reclaim type fall back when isolation makes no progress Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-04-28 4:18 ` Kairui Song
2026-04-27 18:06 ` [PATCH v7 07/15] mm/mglru: use a smaller batch for reclaim Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 08/15] mm/mglru: don't abort scan immediately right after aging Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 09/15] mm/mglru: remove redundant swap constrained check upon isolation Kairui Song
2026-04-27 18:07 ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 10/15] mm/mglru: use the common routine for dirty/writeback reactivation Kairui Song
2026-04-27 18:07 ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 11/15] mm/mglru: simplify and improve dirty writeback handling Kairui Song
2026-04-27 18:07 ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 12/15] mm/mglru: remove no longer used reclaim argument for folio protection Kairui Song
2026-04-27 18:07 ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 13/15] mm/vmscan: remove sc->file_taken Kairui Song
2026-04-27 18:07 ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 14/15] mm/vmscan: remove sc->unqueued_dirty Kairui Song
2026-04-27 18:07 ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 15/15] mm/vmscan: unify writeback reclaim statistic and throttling Kairui Song
2026-04-27 18:07 ` Kairui Song via B4 Relay
2026-04-27 18:22 ` [PATCH v7 00/15] mm/mglru: improve reclaim loop and dirty folio handling Andrew Morton
2026-05-11 18:51 ` Shakeel Butt
2026-05-12 5:08 ` Kairui Song
2026-05-12 5:56 ` Shakeel Butt
2026-05-27 1:35 ` Andrew Morton
2026-05-27 3:25 ` Shakeel Butt [this message]
2026-05-27 5:36 ` Kairui Song
2026-05-27 20:40 ` Andrew Morton
2026-05-14 18:50 ` Kairui Song
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=ahZjvYs83591EYXW@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=chenridong@huaweicloud.com \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kaleshsingh@google.com \
--cc=laoar.shao@gmail.com \
--cc=lenohou@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=ryncsn@gmail.com \
--cc=stevensd@google.com \
--cc=surenb@google.com \
--cc=vernon2gm@gmail.com \
--cc=wangzicheng@honor.com \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=yuzhao@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.