From: Vishal Moola <vishal.moola@gmail.com>
To: Bunyod Suvonov <b.suvonov@sjtu.edu.cn>
Cc: akpm@linux-foundation.org, vbabka@kernel.org, linux-mm@kvack.org,
rostedt@goodmis.org, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com,
linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
surenb@google.com, mhocko@suse.com, jackmanb@google.com,
hannes@cmpxchg.org, ziy@nvidia.com
Subject: Re: [PATCH] mm/page_alloc: add tracepoint for PCP refills
Date: Sun, 26 Apr 2026 15:06:35 -0700 [thread overview]
Message-ID: <ae6Ma68umBlqVdSP@fedora> (raw)
In-Reply-To: <20260425091335.346504-1-b.suvonov@sjtu.edu.cn>
On Sat, Apr 25, 2026 at 05:13:35PM +0800, Bunyod Suvonov wrote:
> The page allocator already has mm_page_pcpu_drain to trace pages
> drained from the per-cpu page lists back to the buddy allocator. There
> is no matching tracepoint for the opposite direction, where
> rmqueue_bulk() refills a PCP list from the buddy allocator.
This sounds like a reasonable idea. Does this tracepoint show us
something that a workload might care about? Not opposed, just curious.
For future versions, would you mind including documentation about it
in Documentation/trace/events-kmem.rst?
> mm_page_alloc_zone_locked is not a good substitute for this. It is
> emitted from __rmqueue_smallest(), which is used both by rmqueue_bulk()
> and by the direct buddy allocation path. Its percpu_refill field is
> derived from the allocation order and migratetype, so it does not
> reliably identify whether the allocation came from a PCP refill.
>
> Add mm_page_pcpu_refill and emit it from rmqueue_bulk() for each page
> added to the PCP list. The new tracepoint uses the same page, order and
> migratetype fields as mm_page_pcpu_drain, making refill and drain
> activity directly comparable.
>
> Signed-off-by: Bunyod Suvonov <b.suvonov@sjtu.edu.cn>
> ---
> include/trace/events/kmem.h | 23 +++++++++++++++++++++++
> mm/page_alloc.c | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> index cd7920c81f85..16985604fc51 100644
> --- a/include/trace/events/kmem.h
> +++ b/include/trace/events/kmem.h
> @@ -243,6 +243,29 @@ DEFINE_EVENT(mm_page, mm_page_alloc_zone_locked,
> TP_ARGS(page, order, migratetype, percpu_refill)
> );
>
> +TRACE_EVENT(mm_page_pcpu_refill,
> +
> + TP_PROTO(struct page *page, unsigned int order, int migratetype),
> +
> + TP_ARGS(page, order, migratetype),
> +
> + TP_STRUCT__entry(
> + __field( unsigned long, pfn )
> + __field( unsigned int, order )
> + __field( int, migratetype )
> + ),
> +
> + TP_fast_assign(
> + __entry->pfn = page ? page_to_pfn(page) : -1UL;
> + __entry->order = order;
> + __entry->migratetype = migratetype;
> + ),
> +
> + TP_printk("page=%p pfn=0x%lx order=%d migratetype=%d",
> + pfn_to_page(__entry->pfn), __entry->pfn,
> + __entry->order, __entry->migratetype)
> +);
> +
> TRACE_EVENT(mm_page_pcpu_drain,
>
> TP_PROTO(struct page *page, unsigned int order, int migratetype),
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 65e205111553..a60b73ed39a4 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2544,6 +2544,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order,
> * pages are ordered properly.
> */
> list_add_tail(&page->pcp_list, list);
> + trace_mm_page_pcpu_refill(page, order, migratetype);
If you're trying to trace all pages as they come onto the pcp lists,
should you also account for the free_frozen_page_commit() path?
> }
> spin_unlock_irqrestore(&zone->lock, flags);
>
> --
> 2.53.0
>
next prev parent reply other threads:[~2026-04-26 22:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-25 9:13 [PATCH] mm/page_alloc: add tracepoint for PCP refills Bunyod Suvonov
2026-04-26 22:06 ` Vishal Moola [this message]
2026-04-27 6:01 ` [PATCH v2] mm/page_alloc: trace PCP refills and PCP zone lock usage Bunyod Suvonov
2026-04-27 6:21 ` SUVONOV BUNYOD
2026-04-28 18:23 ` Steven Rostedt
2026-04-29 3:31 ` SUVONOV BUNYOD
2026-04-29 14:52 ` Steven Rostedt
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=ae6Ma68umBlqVdSP@fedora \
--to=vishal.moola@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=b.suvonov@sjtu.edu.cn \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=rostedt@goodmis.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--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.