From: Zhang Peng <zippermonkey@icloud.com>
To: Barry Song <baohua@kernel.org>
Cc: Zhang Peng <zippermonkey@icloud.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Qi Zheng <qi.zheng@linux.dev>,
"Liam R. Howlett" <liam@infradead.org>,
Kairui Song <kasong@tencent.com>,
Zhang Peng <bruzzhang@tencent.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/5] mm/vmscan: extract pageout_one() from shrink_folio_list()
Date: Sun, 20 Sep 2026 22:46:46 +0800 [thread overview]
Message-ID: <20260920144647.43333-1-zippermonkey@icloud.com> (raw)
In-Reply-To: <CAGsJ_4zOfR3Rn5tk_RcOWUDmREO1JyRwXA15Vr3aeUs=+ybMMA@mail.gmail.com>
[Resending this one on its own - my first attempt accidentally sent
all four replies concatenated into a single mail, see
https://lore.kernel.org/all/20260920143816.39827-1-zippermonkey@icloud.com/
Sorry for the noise.]
On Fri, Aug 14, 2026 at 5:49 AM Barry Song <baohua@kernel.org> wrote:
>
> Also, this patch looks basically good, just like the previous one.
> Could we also avoid hiding the activation semantics in the inner
> function? It would be clearer to make the activation semantics
> explicit at the outer level, so readers don't have to dig into a
> deep internal function to realize that a folio may take the
> activation path.
>
> In LRU, we have two distinct possibilities: activate a folio or just
> keep it. This is an important semantic distinction in the LRU logic.
> Hiding the activation decision so deep in an inner function makes
> that semantic much less obvious.
Done, same treatment as 2/5 - the helper reports the decision and the
caller acts on it:
enum folio_pageout_result {
FOLIO_PAGEOUT_KEEP_LOCKED,
FOLIO_PAGEOUT_KEEP_UNLOCKED,
FOLIO_PAGEOUT_ACTIVATE,
FOLIO_PAGEOUT_FREE, /* folio is locked, hand it to
folio_try_reclaim_free() */
};
switch (folio_try_pageout(folio, sc, &ctx, folio_list)) {
case FOLIO_PAGEOUT_ACTIVATE:
goto activate_locked;
case FOLIO_PAGEOUT_KEEP_LOCKED:
goto keep_locked;
case FOLIO_PAGEOUT_KEEP_UNLOCKED:
goto keep;
case FOLIO_PAGEOUT_FREE:
break; /* folio is locked; try to free it below */
}
Two things beyond what you asked for, both because pageout() has more
outcomes than the freeing path does:
- "keep" is split into KEEP_LOCKED and KEEP_UNLOCKED. pageout() can
return with the folio either still locked or already unlocked, and
previously the caller had to know which internal branch it came
from to pick between the keep_locked and keep labels. Now the
result says so.
- FOLIO_PAGEOUT_FREE keeps the "and now try to free it" step at the
outer level too, instead of chaining into folio_try_reclaim_free()
from inside folio_try_pageout().
This patch is in the cleanup-only series, see my reply on 5/5.
Thanks
Zhang Peng
next prev parent reply other threads:[~2026-09-20 14:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 5:07 [PATCH v5 0/5] mm: batch TLB flushing for dirty folios in vmscan Zhang Peng
2026-07-20 5:07 ` [PATCH v5 1/5] mm/vmscan: introduce folio_activate_locked() helper Zhang Peng
2026-08-10 8:36 ` Barry Song
2026-09-20 14:38 ` Zhang Peng
2026-09-20 21:36 ` Barry Song
2026-09-20 21:49 ` Barry Song
2026-07-20 5:07 ` [PATCH v5 2/5] mm/vmscan: extract folio_free() from shrink_folio_list() Zhang Peng
2026-08-13 21:40 ` Barry Song
2026-09-20 14:45 ` Zhang Peng
2026-07-20 5:07 ` [PATCH v5 3/5] mm/vmscan: extract pageout_one() " Zhang Peng
2026-08-13 21:49 ` Barry Song
2026-09-20 14:46 ` Zhang Peng [this message]
2026-07-20 5:07 ` [PATCH v5 4/5] mm/vmscan: extract folio unmap logic into folio_try_unmap() Zhang Peng
2026-08-13 21:52 ` Barry Song
2026-07-20 5:07 ` [PATCH v5 5/5] mm/vmscan: flush TLB for every 31 folios evictions Zhang Peng
2026-08-13 21:58 ` Barry Song
2026-09-20 14:47 ` Zhang Peng
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=20260920144647.43333-1-zippermonkey@icloud.com \
--to=zippermonkey@icloud.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=bruzzhang@tencent.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=qi.zheng@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=weixugc@google.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.