From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FEB4C83F17 for ; Tue, 15 Jul 2025 17:17:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E45B96B0092; Tue, 15 Jul 2025 13:17:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1D976B0093; Tue, 15 Jul 2025 13:17:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5A886B0095; Tue, 15 Jul 2025 13:17:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C8B5B6B0092 for ; Tue, 15 Jul 2025 13:17:26 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4597C1D355B for ; Tue, 15 Jul 2025 17:17:26 +0000 (UTC) X-FDA: 83667155292.08.640EAC4 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf10.hostedemail.com (Postfix) with ESMTP id 5B856C0015 for ; Tue, 15 Jul 2025 17:17:24 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PvDL+PNU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of kuniyu@google.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=kuniyu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752599844; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NBzJE6YTkZ03D0TDxsw4pCwiNvK6jQyXb6N1iVx/Fl8=; b=byOBwuStlqWjRzR71qrDTwf15TYfQEgCXm6YuJszxtascI1sX2TmteoxWzZBd+8VJ144NJ lHKQx7+Y2Owmpfmp/3qnzmplBU5ITyrgz6Tag1Yht0r4hZXt+UDu7otVhYSwd26XLeeR2W sUpfM/XiruVo5FtPaw6OtUJ2S9TxO9Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752599844; a=rsa-sha256; cv=none; b=GK0vajvODwenkjmjICv3tRX7o4tKmJjsnWJ/ukslpnoaXdMGeXRF4Sp+YFXOvV0EQ9hnn/ L+9JYXKQQfq40hRLumtijeIqY7JiAa+HO/HV3xnbSFqW1Wtsl3E7zxwX91y9zY7cLffr3p D4G2SjyZQ08wW4Y1kjRIJZTgAZw58fg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PvDL+PNU; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of kuniyu@google.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=kuniyu@google.com Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-311d5fdf1f0so5165931a91.1 for ; Tue, 15 Jul 2025 10:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752599843; x=1753204643; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NBzJE6YTkZ03D0TDxsw4pCwiNvK6jQyXb6N1iVx/Fl8=; b=PvDL+PNUfbOQQN+1kNDGTjbbstGxknr/c25rSWd08yoMN3+Vamfl5dZ9v8i+YKPobU +Ljg9nMECpAkOa9VYivs05P6h48nPzl2YrPDUj0fdewbLVxU0OrGCJwWoTF76doGDZRZ 4CkGeUggOsGl52PhtvaAbGvMxPt5xadmJS8kJQ5b+WsMhIHzQdpG4DVgRxlZBOCGSsaz TOO4bqPZH1/cRbrTPNj2FEHpISV1oT8VHgA89RPlxmG42Hj9sdRtGNCcw7BzBdBsiICA 1r4iIlg68Vm86SXLgOKpdQhJeZGrUiQ83TkgHraymiRqb4S7nYBaaHNvVjlb2J8GEiro M3uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752599843; x=1753204643; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NBzJE6YTkZ03D0TDxsw4pCwiNvK6jQyXb6N1iVx/Fl8=; b=lg55edO6pQGKu6VS+ej2COmNMh+By+XZPS5AHEjpsFhrHMhUZuE1degB7LYk6m4PTd ChJR09j+cEHpqp7TBLKkSgTIa6iPyN/1+856tM/Wm7kgp4iNt8wx+x/3YywMifP+Q0BX cE28brqEOVuxCnuhkz9QYR55llb7WKkooJnVlGkG6vu3DiwWvjnY97yUzNH/L/AH6itA O37FozrPGY3GOyvxi8uM6m1SGmCemU7Y9qlcZGEJ8NGuKEREZ9dTBzI4+RNdVVsTsVJh Q4i6kZkGwWZV4Hh/eZLr66YMmLt6sPqDmuHZKRUCs++xH/wUdV8W3rW0cvPxALZSQBvM ILEg== X-Forwarded-Encrypted: i=1; AJvYcCUddAuMrPz93+kVRkihrOVwHv2/5UJ0VcgkAtcgM+jjBekqgSCTNaL2Akg+B1RIKMAfQsvYa9oebQ==@kvack.org X-Gm-Message-State: AOJu0YwXEVoHtoAqlM6YyjEjX9q+sfNZvnhXayv42ATuqc2zs+WQWUrM 7cHQQQpNX7c6dZmp++OWgplTcXyV7zn0Rl8ILwKSvcO317u0+wHu2f2+PK2OrRhfftM4OJ5avbq Rx+AAjB8jcIBvG4LOwqmOH79Zf+20rtktsZEK9OQA X-Gm-Gg: ASbGnctdCXtSd62xk9l56x4s5RGF3OS3Z8VE2/37p9QYnTJXor7w12jS/R1g4sIGvMw LK6gvCW/Gz7l2zHy2aX+k0uPJ5cbBparRmjk6aXkL4VBqoBVo01fzO26Jlz4OFFWI5Qbi9jAViV W/TPykVyBxOVYl2+PoEGbLEAOejU6Pl9S5lS00Dz9Zkhfd+bdcLhV80qZpLiZEvU0SNq/jz6825 Kgy/HJWSgqzGFZhKT9wWu0OhRqw5ONhNQQBzQ== X-Google-Smtp-Source: AGHT+IGS8Ve0NO4yhzFG58PVCTwdeB58lMcBo/7XS0S6ewWfzz9MR/+K/WG+zCR7MSrZ7bk3WMQHdvkbVWJOzYyeylQ= X-Received: by 2002:a17:90b:3a08:b0:313:283e:e881 with SMTP id 98e67ed59e1d1-31c4ca84a5fmr30431933a91.11.1752599842821; Tue, 15 Jul 2025 10:17:22 -0700 (PDT) MIME-Version: 1.0 References: <20250714143613.42184-1-daniel.sedlak@cdn77.com> <20250714143613.42184-3-daniel.sedlak@cdn77.com> <8a7cea99-0ab5-4dba-bc89-62d4819531eb@cdn77.com> In-Reply-To: <8a7cea99-0ab5-4dba-bc89-62d4819531eb@cdn77.com> From: Kuniyuki Iwashima Date: Tue, 15 Jul 2025 10:17:11 -0700 X-Gm-Features: Ac12FXx9tRWpu9itogCzIOsSORL988MXK7dQ7rkzsNG49_Rp-vtFHy2swBsO4X0 Message-ID: Subject: Re: [PATCH v2 net-next 2/2] mm/vmpressure: add tracepoint for socket pressure detection To: Daniel Sedlak Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Neal Cardwell , David Ahern , Andrew Morton , Shakeel Butt , Yosry Ahmed , linux-mm@kvack.org, netdev@vger.kernel.org, Matyas Hurtik , Daniel Sedlak Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5B856C0015 X-Stat-Signature: ngch774o7zyzxo7uesueh7bfpwwypbfz X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1752599844-108337 X-HE-Meta: U2FsdGVkX1+7IryZGXihX+UpCxUMJV30N40DZFrr0W0S8Nuxd57d8Q+7M9VcpDhUHYVHMg2gZkGjfTUSpCOkvDxR8Os5AlIBSoDqYwfc8rCdMmyaxaHoRPc5vhSoRcIINozhb4qn7My6yHbf3JTF1riw7bdWogakJTe3qs0yXEtAqB0moZekHQ/fg/k4BkL3UqkI0jdcQBjmlhxVo6YN8cA45QzyNtH8E601ErsQaXQhRNdp/pdOgV2s5htATKfiM+49zwkiCaj9piCdNzDgfgQLRp/84O/zbLnsApMwXaF/u8JVqQOQFn6CX7GZa2CGKgVPbBIZz7kzJp2fEvrmnT6GnAkdDRRR84zddDAwIH01dJXSfRK0iq7lupfT3f4VBk0scUTlc51oNQj/sELUqJTxeCYGRky+YEQSclQvMfg4A0YFJTVzo17VYIik09NnV1iKobgsIj9lnotRyeS4/tzEaoOSN5OK/Tu7QUyjv+fQqTs88l5XxwMPABVWbYKu5RZsPGX90tMKwb6FUSYfeyNU9LZqxhKpoga2QgbiBq7qe4AGTmjqU/RV+8n1E6BGIaNLQdbqFRQJQiuwyvsWuRBYme9Qkc5ez1KzQQQ2+Tmh3U6sSQUTSSr+z/LKl6dGzJrU6wGU0toVuyPZXcneJWo259izLvERnGs6PkJJ4y1HBLReKSmD/kDOH19rjLCGSqUV8Wqm/FyYWBXXW5J7zS9rPraf93vxXnw/UIE/vAz3MKa6JcShInJbDoUZ9KkE88SVwORSj+k0AzoGyAR0W0Wxq5S/iaGHxZKDdEcs9kDm+ve+o0MNR3t/j2IDqznXFMX+0RT6kpApP8iNnD5tbTb3islMfza2rB8FKtUg5uNx9tL5mmdI2VkEy4NqfReEP43kQFe6RqbNKDYWwBf1YZ3M47lUxFHCM/OePHgL4Uz8/GzhbIq/hx09fI+8xTPoViYAYEWlnzZMOcUrEIs Kbo7nmVf gdszd6gIZ5TetpQ8xDYOV4bzVSI1Y6awoEtnnhydf60eWG9vfbglCjkVUev03BiHeSFdNVOgB9w8Jlh0plMxtRMepbyc0/0WuEtLECxe3o5xEIzGxEzHJ9Vi1Q1p9Gl6Xzi6jEnoLBhGT2gQFSSjv83sVcHObkKuGuIlNMFfpCszVt8O0CGskP7M7fsEiyg4bv8tiFUYcgCrMREBOd3yxbgffGCf+ccDLr3fGI02Lhta6uBctQDyawlJh44AGIWluDcLLY1jLboXpVVRFPuojN8KCyKZVJMeoWHt84v1mDduECFTA7th1yw3TlCnufF1lonnwGf020PUXtTfYgjZacgoRHg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jul 15, 2025 at 12:01=E2=80=AFAM Daniel Sedlak wrote: > > Hi Kuniyuki, > > On 7/14/25 8:02 PM, Kuniyuki Iwashima wrote: > >> +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 =3D cgroup_id(memcg->css.cgroup); > >> + __entry->scanned =3D scanned; > >> + __entry->reclaimed =3D reclaimed; > >> + ), > >> + > >> + TP_printk("memcg_id=3D%llu scanned=3D%lu reclaimed=3D%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. > > 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. > > Link: https://bpftrace.org/docs/latest#functions-cgroup_path [1] > > 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. 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. > > > >> + __entry->scanned, > >> + __entry->reclaimed) > >> +); > >> + > >> #endif /* _TRACE_MEMCG_H */ > >> > >> /* This part must be outside protection */ > >> diff --git a/mm/vmpressure.c b/mm/vmpressure.c > >> index bd5183dfd879..aa9583066731 100644 > >> --- a/mm/vmpressure.c > >> +++ b/mm/vmpressure.c > >> @@ -21,6 +21,8 @@ > >> #include > >> #include > >> > >> +#include > >> + > >> /* > >> * The window size (vmpressure_win) is the number of scanned pages b= efore > >> * we try to analyze scanned/reclaimed ratio. So the window is used = as a > >> @@ -317,6 +319,7 @@ void vmpressure(gfp_t gfp, struct mem_cgroup *memc= g, bool tree, > >> * pressure events can occur. > >> */ > >> WRITE_ONCE(memcg->socket_pressure, jiffies + = HZ); > >> + trace_memcg_socket_under_pressure(memcg, scann= ed, reclaimed); > > > > This is triggered only when we enter the memory pressure state > > and not when we leave the state, right ? Is it possible to issue > > such an event ? > > AFAIK, the currently used API in the vmpressure function does not have > anything like enter or leave the socket memory pressure state. It only > periodically re-arms the socket pressure for a specific duration. So the > current tracepoint is called when the socket pressure is re-armed. > > I am not sure how feasible it is to rewrite it so we have enter and > leave logic. I am not that familiar with those code paths. Unlike tcp mem pressure, the memcg pressure only persists for one second, so it won't make sense to add the "leave" event, and I guess the assumption would be that socket_pressure will keep updated under memory pressure.