Re: [PATCH v2 net-next 2/2] mm/vmpressure: add tracepoint for socket pressure detection

On Tue, Jul 15, 2025 at 10:17 AM Kuniyuki Iwashima [off-list ref] wrote:

On Tue, Jul 15, 2025 at 12:01 AM Daniel Sedlak [off-list ref] wrote:

quoted

Hi Kuniyuki,

On 7/14/25 8:02 PM, Kuniyuki Iwashima wrote:

quoted

quoted

+TRACE_EVENT(memcg_socket_under_pressure,
+
+       TP_PROTO(const struct mem_cgroup *memcg, unsigned long scanned,
+               unsigned long reclaimed),
+
+       TP_ARGS(memcg, scanned, reclaimed),
+
+       TP_STRUCT__entry(
+               __field(u64, id)
+               __field(unsigned long, scanned)
+               __field(unsigned long, reclaimed)
+       ),
+
+       TP_fast_assign(
+               __entry->id = cgroup_id(memcg->css.cgroup);
+               __entry->scanned = scanned;
+               __entry->reclaimed = reclaimed;
+       ),
+
+       TP_printk("memcg_id=%llu scanned=%lu reclaimed=%lu",
+               __entry->id,

Maybe a noob question: How can we translate the memcg ID
to the /sys/fs/cgroup/... path ?

IMO this should be really named `cgroup_id` instead of `memcg_id`, but
we kept the latter to keep consistency with the rest of the file.

To find cgroup path you can use:
- find /sys/fs/cgroup/ -inum `memcg_id`, and it will print "path" to the
affected cgroup.
- or you can use bpftrace tracepoint hooks and there is a helper
function [1].

Thanks, this is good to know and worth in the commit message.

quoted

Or we can put the cgroup_path to the tracepoint instead of that ID, but
I feel it can be too much overhead, the paths can be pretty long.

Agree, the ID is good enough given we can find the cgroup by oneliner.

quoted

Link: https://bpftrace.org/docs/latest#functions-cgroup_path [1]

quoted

It would be nice to place this patch first and the description of
patch 2 has how to use the new stat with this tracepoint.

Sure, can do that. However, I am unsure how a good idea is to
cross-reference commits, since each may go through a different tree
because each commit is for a different subsystem. They would have to go
through one tree, right?

Right.

Sorry, I meant to say the two patches don't need to go along to a
single tree and you can post them separately as each change is
independent.

Probably you can just assume both patches will be merged
and post the tracepoint patch to mm ML first and then add its
lore.kernel.org link and howto in the stat patch and post it to netdev ML.