All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ridong Chen" <ridong.chen@linux.dev>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] mm/mglru: add tracepoint for scan_folios()
Date: Fri, 11 Sep 2026 07:42:45 +0000	[thread overview]
Message-ID: <20260911074246.03CA11F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260911072848.2346073-3-ridong.chen@linux.dev>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Evaluating pointer dereferences at the tracepoint call site adds unnecessary overhead when tracing is disabled.
--

commit 3d7b5caa2f51b1f8f623f8379f3a020ee141f537
Author: Ridong Chen <chenridong@xiaomi.com>

mm/mglru: add tracepoint for scan_folios()

This commit introduces a new MGLRU-specific tracepoint,
mm_mglru_scan_folios, to report scan and isolate counts along with
MGLRU-specific context like memcg ID, generation, and tier. The tracepoint
is placed alongside the classic-LRU tracepoint in scan_folios().

> diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
> --- a/include/trace/events/vmscan.h
> +++ b/include/trace/events/vmscan.h
[ ... ]
> +TRACE_EVENT(mm_mglru_scan_folios,
> +
> +	TP_PROTO(u64 memcg_id,
> +		int highest_zoneidx,

[Severity: Medium]
Does this prototype incorrectly accept an evaluated u64 instead of a pointer?

Accepting the evaluated value here forces evaluation at the call site.
Could we pass the struct lruvec pointer in the prototype instead, so the
expensive pointer dereferences can happen safely inside TP_fast_assign
where they only execute when tracing is enabled?

> +		int order,
[ ... ]
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
[ ... ]
> @@ -4927,6 +4927,12 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
>  	trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan,
>  				scanned, skipped, isolated,
>  				type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON);
> +	trace_mm_mglru_scan_folios(mem_cgroup_id(lruvec_memcg(lruvec)),
> +				   sc->reclaim_idx, sc->order, nr_to_scan,

[Severity: Medium]
Can this introduce unnecessary overhead on the memory reclaim hot path?

Because trace_mm_mglru_scan_folios evaluates its arguments before checking
the tracepoint's static key, calling mem_cgroup_id(lruvec_memcg(lruvec))
here forces multiple pointer dereferences to happen unconditionally.

The compiler cannot optimize them into the inactive branch because it cannot
prove the arbitrary pointer accesses won't trap. Placing the dereferences
inside TP_fast_assign avoids this execution when tracing is disabled.

> +				   scanned, sorted, skipped, isolated,
> +				   type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON,
> +				   lrugen->max_seq, tier,
> +				   lrugen->min_seq[type]);
>  
>  	*isolatedp = isolated;
>  	return scanned;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911072848.2346073-1-ridong.chen@linux.dev?part=2

  reply	other threads:[~2026-09-11  7:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11  7:28 [PATCH 0/3] mm/mglru: add tracepoints for scan and aging paths Ridong Chen
2026-09-11  7:28 ` [PATCH 1/3] mm/mglru: factor out lru_gen_seq_nr_pages() Ridong Chen
2026-09-11  7:28 ` [PATCH 2/3] mm/mglru: add tracepoint for scan_folios() Ridong Chen
2026-09-11  7:42   ` sashiko-bot [this message]
2026-09-11 10:04     ` Ridong Chen
2026-09-11 14:11   ` Steven Rostedt
2026-09-13 10:25     ` Ridong Chen
2026-09-11  7:28 ` [PATCH 3/3] mm/mglru: add tracepoint for inc_max_seq() Ridong Chen
2026-09-11 14:15   ` Steven Rostedt
2026-09-13 10:28     ` Ridong Chen

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=20260911074246.03CA11F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=ridong.chen@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.