From: Shakeel Butt <shakeel.butt@linux.dev>
To: JP Kobryn <jp.kobryn@linux.dev>
Cc: Barry Song <baohua@kernel.org>,
linux-mm@kvack.org, willy@infradead.org, usama.arif@linux.dev,
akpm@linux-foundation.org, vbabka@kernel.org, mhocko@suse.com,
rostedt@goodmis.org, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com, kasong@tencent.com,
qi.zheng@linux.dev, axelrasmussen@google.com,
yuanchu@google.com, weixugc@google.com, chrisl@kernel.org,
shikemeng@huaweicloud.com, nphamcs@gmail.com,
baoquan.he@linux.dev, youngjun.park@lge.com,
linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/lruvec: trace LRU add drains and drain-all queuing
Date: Tue, 9 Jun 2026 18:21:00 -0700 [thread overview]
Message-ID: <aii7WWFmAyoXn9rk@linux.dev> (raw)
In-Reply-To: <d676cf78-4b0a-4d6b-b322-f64826aaca75@linux.dev>
On Tue, Jun 09, 2026 at 05:16:15PM -0700, JP Kobryn wrote:
> On 6/9/26 5:07 PM, JP Kobryn wrote:
> > On 6/9/26 12:44 AM, Barry Song wrote:
> >> On Tue, Jun 9, 2026 at 12:12 PM JP Kobryn <jp.kobryn@linux.dev> wrote:
> >>>
> >>> LRU add batches can be drained before they reach capacity. This can be a
> >>> source of LRU lock contention, but it is not currently possible to
> >>> attribute these drains to callers with existing tracepoints.
> >>>
> >>> Add mm_lru_add_drain to report the CPU and lru_add batch count when an
> >>> lru_add batch is drained. This allows tracing to distinguish full drains
> >>> from partial drains and attribute them to the calling stack.
> >>>
> >>> Add mm_lru_drain_all_queue to report when lru_add_drain_all() queues
> >>> per-CPU drain work. This captures the requester stack and target CPU for
> >>> remote drain work. The event is named as a drain-all queue event because
> >>> the queued work can be needed for batches other than lru_add.
> >>>
> >>> Signed-off-by: JP Kobryn <jp.kobryn@linux.dev>
> >>> ---
> >>> include/trace/events/pagemap.h | 40 ++++++++++++++++++++++++++++++++++
> >>> mm/swap.c | 6 ++++-
> >>> 2 files changed, 45 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/include/trace/events/pagemap.h b/include/trace/events/pagemap.h
> >>> index 171524d3526d..ea8fc46bedb0 100644
> >>> --- a/include/trace/events/pagemap.h
> >>> +++ b/include/trace/events/pagemap.h
> >>> @@ -77,6 +77,46 @@ TRACE_EVENT(mm_lru_activate,
> >>> TP_printk("folio=%p pfn=0x%lx", __entry->folio, __entry->pfn)
> >>> );
> >>>
> >>> +TRACE_EVENT(mm_lru_add_drain,
> >>> +
> >>> + TP_PROTO(int cpu, unsigned int nr),
> >>> +
> >>> + TP_ARGS(cpu, nr),
> >>> +
> >>> + TP_STRUCT__entry(
> >>> + __field(int, cpu )
> >>> + __field(unsigned int, nr )
> >>> + ),
> >>> +
> >>> + TP_fast_assign(
> >>> + __entry->cpu = cpu;
> >>> + __entry->nr = nr;
> >>> + ),
> >>> +
> >>> + TP_printk("cpu=%d nr=%u", __entry->cpu, __entry->nr)
> >>> +);
> >>> +
> >>> +TRACE_EVENT(mm_lru_drain_all_queue,
> >>> +
> >>> + TP_PROTO(int target_cpu, bool force_all_cpus),
> >>> +
> >>> + TP_ARGS(target_cpu, force_all_cpus),
> >>> +
> >>> + TP_STRUCT__entry(
> >>> + __field(int, target_cpu )
> >>> + __field(bool, force_all_cpus )
> >>> + ),
> >>> +
> >>> + TP_fast_assign(
> >>> + __entry->target_cpu = target_cpu;
> >>> + __entry->force_all_cpus = force_all_cpus;
> >>> + ),
> >>> +
> >>> + TP_printk("target_cpu=%d force_all_cpus=%s",
> >>> + __entry->target_cpu,
> >>> + __entry->force_all_cpus ? "true" : "false")
> >>> +);
> >>> +
> >>> #endif /* _TRACE_PAGEMAP_H */
> >>>
> >>> /* This part must be outside protection */
> >>> diff --git a/mm/swap.c b/mm/swap.c
> >>> index 588f50d8f1a8..c385b93582eb 100644
> >>> --- a/mm/swap.c
> >>> +++ b/mm/swap.c
> >>> @@ -694,9 +694,12 @@ void lru_add_drain_cpu(int cpu)
> >>> {
> >>> struct cpu_fbatches *fbatches = &per_cpu(cpu_fbatches, cpu);
> >>> struct folio_batch *fbatch = &fbatches->lru_add;
> >>> + unsigned int nr_folios_add = folio_batch_count(fbatch);
> >>>
> >>> - if (folio_batch_count(fbatch))
> >>> + if (nr_folios_add) {
> >>> folio_batch_move_lru(fbatch, lru_add);
> >>> + trace_mm_lru_add_drain(cpu, nr_folios_add);
> >>> + }
> >>>
> >>> fbatch = &fbatches->lru_move_tail;
> >>> /* Disabling interrupts below acts as a compiler barrier. */
> >>> @@ -928,6 +931,7 @@ static inline void __lru_add_drain_all(bool force_all_cpus)
> >>> if (cpu_needs_drain(cpu)) {
> >>> INIT_WORK(work, lru_add_drain_per_cpu);
> >>> queue_work_on(cpu, mm_percpu_wq, work);
> >>> + trace_mm_lru_drain_all_queue(cpu, force_all_cpus);
> >>
> >> Do you need tracing on each CPU individually, or is tracing the
> >> entire __lru_add_drain_all() invocation sufficient?
> >
> > I think the latter would be fine. The remote work will invoke the
> > mm_lru_add_drain tracepoint, which will show up as kworker stacks. Since
> > the event already has the CPU, we could see where queued drains actually
> > ran.
>
> Actually if it's just a single invocation and the only event data is the
> force flag, a tracepoint may not even be needed. Other probes can be
> installed on function invocation and read the single argument. I can
> drop this from v2 and keep the single mm_lru_add_drain tracepoint.
No we do want to trace the callers requesting to drain from all the CPUs. If you
trace just lru_add_drain_cpu() then you will only see that the drain is
requested for a given CPU but no information on the requester.
Also as Barry said, I think single trace for whole __lru_add_drain_all() is good
enough.
prev parent reply other threads:[~2026-06-10 1:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 4:11 [PATCH] mm/lruvec: trace LRU add drains and drain-all queuing JP Kobryn
2026-06-09 7:44 ` Barry Song
2026-06-10 0:07 ` JP Kobryn
2026-06-10 0:16 ` JP Kobryn
2026-06-10 1:21 ` Shakeel Butt [this message]
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=aii7WWFmAyoXn9rk@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=chrisl@kernel.org \
--cc=jp.kobryn@linux.dev \
--cc=kasong@tencent.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=nphamcs@gmail.com \
--cc=qi.zheng@linux.dev \
--cc=rostedt@goodmis.org \
--cc=shikemeng@huaweicloud.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=youngjun.park@lge.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox