All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yajun Deng" <yajun.deng@linux.dev>
To: "Johannes Weiner" <hannes@cmpxchg.org>
Cc: akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com,
	mhocko@suse.com, jackmanb@google.com, ziy@nvidia.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	"Joshua Hahn" <joshua.hahnjy@gmail.com>
Subject: Re: [PATCH v2] mm/page_alloc: Avoid duplicate NR_FREE_PAGES updates in move_to_free_list()
Date: Tue, 13 Jan 2026 07:13:39 +0000	[thread overview]
Message-ID: <5cda8821bd3ac432a06698fa7eebdab0aff77452@linux.dev> (raw)
In-Reply-To: <aWUKKyBZzsCBELLi@cmpxchg.org>

January 12, 2026 at 10:50 PM, "Johannes Weiner" <hannes@cmpxchg.org mailto:hannes@cmpxchg.org?to=%22Johannes%20Weiner%22%20%3Channes%40cmpxchg.org%3E > wrote:


> 
> On Mon, Jan 12, 2026 at 08:16:14PM +0800, Yajun Deng wrote:
> 
> > 
> > In move_to_free_list(), when a page block changes its migration type,
> >  we need to update free page counts for both the old and new types.
> >  Originally, this was done by two calls to account_freepages(), which
> >  updates NR_FREE_PAGES and also type-specific counters. However, this
> >  causes NR_FREE_PAGES to be updated twice, while the net change is zero
> >  in most cases.
> >  
> >  This patch adds a condition that updates the NR_FREE_PAGES only if one of
> >  the two types is the isolate type. This avoids NR_FREE_PAGES being
> >  updates twice.
> >  
> >  The optimization avoid duplicate NR_FREE_PAGES updates in
> >  move_to_free_list().
> >  
> >  Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
> >  Suggested-by: Joshua Hahn <joshua.hahnjy@gmail.com>
> > 
> I'm not a fan of this.
> 
> The code ends up more complicated, more lines, and fragile because the
> accounting decisions are now spread out over multiple places (again).
> 
How about V1? It will introduce account_freepages_both().
https://lore.kernel.org/all/20260109105121.328780-1-yajun.deng@linux.dev/

> Is it worth it? move_to_free_list() is used in page isolation, which
> has to do the accounting anyway; and migratetype fallbacks, which we
> are trying to avoid as much as possible. So this path shouldn't be all
> that hot to begin with.
> 
Not all cases are of the isolation type. There are indeed duplicate caculations.
move_freepages_block() will be called in __isolate_free_page().
Both old_mt and new_mt are mergeable type in this case.

> Simplicity & maintainability trumps here, IMO, unless you have hard
> data showing this is worth the pain.
>
I'm tring to do it, but I haven't yet.


  reply	other threads:[~2026-01-13  7:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12 12:16 [PATCH v2] mm/page_alloc: Avoid duplicate NR_FREE_PAGES updates in move_to_free_list() Yajun Deng
2026-01-12 14:50 ` Johannes Weiner
2026-01-13  7:13   ` Yajun Deng [this message]
2026-01-20 10:16     ` Vlastimil Babka
2026-01-12 14:53 ` Joshua Hahn
2026-01-17 14:15 ` Markus Elfring

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=5cda8821bd3ac432a06698fa7eebdab0aff77452@linux.dev \
    --to=yajun.deng@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=jackmanb@google.com \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --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 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.