From: Johannes Weiner <hannes@cmpxchg.org>
To: Rik van Riel <riel@surriel.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Zi Yan <ziy@nvidia.com>, Kairui Song <kasong@tencent.com>,
Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Baoquan He <baoquan.he@linux.dev>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Mike Rapoport <rppt@kernel.org>,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 2/5] mm/page_alloc: count a merged buddy's pages under the merged type
Date: Wed, 14 Oct 2026 22:40:42 +0200 [thread overview]
Message-ID: <20261014204042.GH371161@cmpxchg.org> (raw)
In-Reply-To: <20261007021250.1665929-3-riel@surriel.com>
On Tue, Oct 06, 2026 at 10:12:47PM -0400, Rik van Riel wrote:
> __free_one_page() merges a freed page with a free buddy of another
> mergeable type at pageblock order and above, and retypes the buddy to
> match. The buddy's pages stay counted under the old type: nothing moves
> them to the merged type in the free counts.
>
> That is unobservable today. NR_FREE_PAGES does not separate types, so the
> missing move nets to zero there. Any future per-type free count would
> undercount on a merge from the other side, and allocating the merged
> run later could wrap it.
>
> Move the buddy's pages to the merged type in the count too.
>
> Assisted-by: LLM
> Signed-off-by: Rik van Riel <riel@surriel.com>
> ---
> mm/page_alloc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4658af97be010..ae38e25971559 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -993,6 +993,11 @@ static inline void __free_one_page(struct page *page,
> account_freepages(zone, 1 << order, migratetype);
> } else {
> __del_page_from_free_list(buddy, zone, order, buddy_mt);
> + /* The buddy's free pages join the merged block's type. */
> + if (unlikely(buddy_mt != migratetype)) {
> + account_freepages(zone, -(1 << order), buddy_mt);
> + account_freepages(zone, 1 << order, migratetype);
Reasonable on one hand, but I think at that point it would be simpler
and more robust to drop that 'single account_freepages() + __add/__del
operations' optimization, and just use the accounting add/del variants
directly instead.
next prev parent reply other threads:[~2026-10-14 20:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 2:12 [RFC PATCH 0/5] mm/page_alloc: keep non-movable pages out of movable pageblocks for THP Rik van Riel
2026-10-07 2:12 ` [RFC PATCH 1/5] mm/page_alloc: count guard pages as free again when their buddy merges Rik van Riel
2026-10-14 13:43 ` Dev Jain
2026-10-14 20:37 ` Johannes Weiner
2026-10-14 20:57 ` Zi Yan
2026-10-07 2:12 ` [RFC PATCH 2/5] mm/page_alloc: count a merged buddy's pages under the merged type Rik van Riel
2026-10-14 14:16 ` Dev Jain
2026-10-14 14:27 ` Rik van Riel
2026-10-14 15:19 ` Dev Jain
2026-10-14 15:40 ` Rik van Riel
2026-10-14 20:40 ` Johannes Weiner [this message]
2026-10-07 2:12 ` [RFC PATCH 3/5] mm/page_alloc: convert any movable pageblock on a non-movable allocation Rik van Riel
2026-10-14 20:48 ` Johannes Weiner
2026-10-14 20:53 ` Rik van Riel
2026-10-07 2:12 ` [RFC PATCH 4/5] mm/page_alloc: skip movable blocks during non-movable steals Rik van Riel
2026-10-07 2:12 ` [RFC PATCH 5/5] mm/page_alloc: claim blocks captured for non-movable use Rik van Riel
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=20261014204042.GH371161@cmpxchg.org \
--to=hannes@cmpxchg.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=brendan.jackman@linux.dev \
--cc=david@kernel.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@suse.com \
--cc=qi.zheng@linux.dev \
--cc=riel@surriel.com \
--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 \
--cc=ziy@nvidia.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