From: SeongJae Park <sj@kernel.org>
To: Joshua Hahn <joshua.hahnjy@gmail.com>
Cc: SeongJae Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>, Chris Mason <clm@fb.com>,
Kiryl Shutsemau <kirill@shutemov.name>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Brendan Jackman <jackmanb@google.com>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Michal Hocko <mhocko@suse.com>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>, Zi Yan <ziy@nvidia.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel-team@meta.com
Subject: Re: [PATCH v2 1/4] mm/page_alloc/vmstat: Simplify refresh_cpu_vm_stats change detection
Date: Fri, 26 Sep 2025 10:50:04 -0700 [thread overview]
Message-ID: <20250926175004.54610-1-sj@kernel.org> (raw)
In-Reply-To: <20250924204409.1706524-2-joshua.hahnjy@gmail.com>
On Wed, 24 Sep 2025 13:44:05 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
> Currently, refresh_cpu_vm_stats returns an int, indicating how many
> changes were made during its updates. Using this information, callers
> like vmstat_update can heuristically determine if more work will be done
> in the future.
>
> However, all of refresh_cpu_vm_stats's callers either (a) ignore the
> result, only caring about performing the updates, or (b) only care about
> whether changes were made, but not *how many* changes were made.
>
> Simplify the code by returning a bool instead to indicate if updates
> were made.
>
> In addition, simplify fold_diff and decay_pcp_high to return a bool
> for the same reason.
>
> Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>
> ---
> include/linux/gfp.h | 2 +-
> mm/page_alloc.c | 8 ++++----
> mm/vmstat.c | 26 +++++++++++++-------------
> 3 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 5ebf26fcdcfa..63c72cb1d117 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -386,7 +386,7 @@ extern void free_pages(unsigned long addr, unsigned int order);
> #define free_page(addr) free_pages((addr), 0)
>
> void page_alloc_init_cpuhp(void);
> -int decay_pcp_high(struct zone *zone, struct per_cpu_pages *pcp);
> +bool decay_pcp_high(struct zone *zone, struct per_cpu_pages *pcp);
> void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp);
> void drain_all_pages(struct zone *zone);
> void drain_local_pages(struct zone *zone);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d1d037f97c5f..77e7d9a5f149 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2561,10 +2561,10 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order,
> * Called from the vmstat counter updater to decay the PCP high.
> * Return whether there are addition works to do.
> */
> -int decay_pcp_high(struct zone *zone, struct per_cpu_pages *pcp)
> +bool decay_pcp_high(struct zone *zone, struct per_cpu_pages *pcp)
> {
> int high_min, to_drain, batch;
> - int todo = 0;
> + bool todo;
I know you and others already found 'todo' should be initialized. :)
[...]
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 71cd1ceba191..1f74a3517ab2 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
[...]
> @@ -839,7 +839,7 @@ static int refresh_cpu_vm_stats(bool do_pagesets)
> if (do_pagesets) {
> cond_resched();
>
> - changes += decay_pcp_high(zone, this_cpu_ptr(pcp));
> + changed |= decay_pcp_high(zone, this_cpu_ptr(pcp));
I'm not a fan of bit operations unless it provides clear benefits.
What about below?
if (decay_pcp_high(zone, this_cpu_ptr(pcp)) && !changed)
changed = truee;
Just a personal and trivial taste. No strong opinion. If you don't strongly
feel my suggestion is better, please keep the original code.
> #ifdef CONFIG_NUMA
> /*
> * Deal with draining the remote pageset of this
> @@ -861,13 +861,13 @@ static int refresh_cpu_vm_stats(bool do_pagesets)
> }
>
> if (__this_cpu_dec_return(pcp->expire)) {
> - changes++;
> + changed = true;
> continue;
> }
>
> if (__this_cpu_read(pcp->count)) {
> drain_zone_pages(zone, this_cpu_ptr(pcp));
> - changes++;
> + changed = true;
> }
> #endif
> }
> @@ -887,8 +887,8 @@ static int refresh_cpu_vm_stats(bool do_pagesets)
> }
> }
>
> - changes += fold_diff(global_zone_diff, global_node_diff);
> - return changes;
> + changed |= fold_diff(global_zone_diff, global_node_diff);
> + return changed;
Ditto.
> }
>
> /*
> --
> 2.47.3
Other than the above trivial things, all looks good to me :)
Thanks,
SJ
next prev parent reply other threads:[~2025-09-26 17:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 20:44 [PATCH v2 0/4] mm/page_alloc: Batch callers of free_pcppages_bulk Joshua Hahn
2025-09-24 20:44 ` [PATCH v2 1/4] mm/page_alloc/vmstat: Simplify refresh_cpu_vm_stats change detection Joshua Hahn
2025-09-24 22:51 ` Christoph Lameter (Ampere)
2025-09-25 18:26 ` Joshua Hahn
2025-09-26 15:34 ` Dan Carpenter
2025-09-26 16:40 ` Joshua Hahn
2025-09-26 17:50 ` SeongJae Park [this message]
2025-09-26 18:24 ` Joshua Hahn
2025-09-26 18:33 ` SeongJae Park
2025-09-24 20:44 ` [PATCH v2 2/4] mm/page_alloc: Perform appropriate batching in drain_pages_zone Joshua Hahn
2025-09-24 23:09 ` Christoph Lameter (Ampere)
2025-09-25 18:44 ` Joshua Hahn
2025-09-26 16:21 ` Christoph Lameter (Ampere)
2025-09-26 17:25 ` Joshua Hahn
2025-10-01 11:23 ` Vlastimil Babka
2025-09-26 14:01 ` Brendan Jackman
2025-09-26 15:48 ` Joshua Hahn
2025-09-26 16:57 ` Brendan Jackman
2025-09-26 17:33 ` Joshua Hahn
2025-09-27 0:46 ` Hillf Danton
2025-09-30 14:42 ` Joshua Hahn
2025-09-30 22:14 ` Hillf Danton
2025-10-01 15:37 ` Joshua Hahn
2025-10-01 23:48 ` Hillf Danton
2025-10-03 8:35 ` Vlastimil Babka
2025-10-03 10:02 ` Hillf Danton
2025-10-04 9:03 ` Mike Rapoport
2025-09-24 20:44 ` [PATCH v2 3/4] mm/page_alloc: Batch page freeing in decay_pcp_high Joshua Hahn
2025-09-24 20:44 ` [PATCH v2 4/4] mm/page_alloc: Batch page freeing in free_frozen_page_commit Joshua Hahn
2025-09-28 5:17 ` kernel test robot
2025-09-29 15:17 ` Joshua Hahn
2025-10-01 10:04 ` Vlastimil Babka
2025-10-01 15:55 ` Joshua Hahn
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=20250926175004.54610-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=clm@fb.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox