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 19339C61DF7 for ; Sat, 25 Nov 2023 06:36:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40ADC8D00B1; Sat, 25 Nov 2023 01:36:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B9748D0096; Sat, 25 Nov 2023 01:36:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A7FA8D00B1; Sat, 25 Nov 2023 01:36:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 173528D0096 for ; Sat, 25 Nov 2023 01:36:21 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DEFD4A0242 for ; Sat, 25 Nov 2023 06:36:20 +0000 (UTC) X-FDA: 81495517320.05.12B869B Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) by imf26.hostedemail.com (Postfix) with ESMTP id 2D053140009 for ; Sat, 25 Nov 2023 06:36:18 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=G7sMyWZV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of 34ZVhZQgKCMQ2rkuoovlqyyqvo.mywvsx47-wwu5kmu.y1q@flex--shakeelb.bounces.google.com designates 209.85.210.202 as permitted sender) smtp.mailfrom=34ZVhZQgKCMQ2rkuoovlqyyqvo.mywvsx47-wwu5kmu.y1q@flex--shakeelb.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700894179; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZHiMIvLDO2ZbTxHRaxuFBOG4CVORHQwJmWn9Lh3DRLs=; b=sBjdf3oK1bWU6Zf+9NWGDIyGi1a7aa+SgfYoM57y/Q82Z4eS9oxt4CvoqM4/ISpOw1/UP0 hFKHnQ1GP2Ig20m2vttHniS/VYXERtGyNe4KCm1fza6+Pbqy7qpiDRCyxdrD4LLWZP6Xvm F/mP4lDK5nYYDfGjdKte9BMEkTWz1Bo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=G7sMyWZV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of 34ZVhZQgKCMQ2rkuoovlqyyqvo.mywvsx47-wwu5kmu.y1q@flex--shakeelb.bounces.google.com designates 209.85.210.202 as permitted sender) smtp.mailfrom=34ZVhZQgKCMQ2rkuoovlqyyqvo.mywvsx47-wwu5kmu.y1q@flex--shakeelb.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700894179; a=rsa-sha256; cv=none; b=MA4T+dg5r63jgRXOJ28h2Y7Vg9KvWveekvRy1nVDg3AdnS7zAWrEFZTYL4SvGgCmzrSNyb 2FU+TDrJRuKkjqbrh3bmL1xiIh+VDxmL76v5UvY4nRSeX54Ts+OVt6fZt2/W27cx8+6ZTH kQbBpJVPCF4Xka39YeR7jmvrN5kT+/A= Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-6c4cf33cf73so3387724b3a.0 for ; Fri, 24 Nov 2023 22:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700894178; x=1701498978; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ZHiMIvLDO2ZbTxHRaxuFBOG4CVORHQwJmWn9Lh3DRLs=; b=G7sMyWZVm0xnMv0kxEFfaaeLKk+oWD6G/HMtIy3Tj31B5qYaOUo53WjVBoHeiGkJlz OZO3+73+AVilHuYqmYZd6QEtF0H0CywlD7n0qhLUxuCagAqXVBMPu8xkq1BI9wUO+khK ZKYd8rX3orE5FtI4RzfMs85WmvZZCSTJnP1mrWRzAHtD1rzCjOA6Huq+tE8qfafo6Tfm ohIai8i2fdzZgnjignVUEwpjZe7ZEvMEhLUEiv12CgwM3/a7nS3iqHlixMwKgo5xqCaQ vV/uCLuz2CiXLo01DubRmio78Q2TAybxvSSq+alMYjN3DKMGsm25MDqz3T/eoysicv0M E+BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700894178; x=1701498978; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZHiMIvLDO2ZbTxHRaxuFBOG4CVORHQwJmWn9Lh3DRLs=; b=JKbLA0D8O1OrCwIHHTi+Vysm5RsLDL5c9VbNvzhZ9ZMp+mAgNi7zAr7VchQzyuYGfD Y5bc+Wz0GY4IpGlskMWZeeX2NoLXDo4XLz6BlbHUZPp92PAdstaEkmi1xHPeAoMPPQR7 5P8xxthce3RViTi89Iqbh4vHfdnXWuzbk+15kjQdl47IkJmae2RyYQBR7f/ukC4YRAA0 fjm0ZmUPDQIDaIyezv+zWFB5PXSW6oFpvmHIP2tih/ajUshvgjJZabBb8S2701bsWQmW KoUZc3X9HrGjzjv4mmSK957JJX0L3ySoBaB5FiQeruFnbDZMEon1bl/SLY1I5PIpMOyR Xulw== X-Gm-Message-State: AOJu0YwPvrxxy5IO4wnQK4W1bRiZ4cYQw2w3gcFdf5MBZIrfmDznUAQ6 jyj+lpRy16ckpl1UFwaB0WPiuTZFyhBh0w== X-Google-Smtp-Source: AGHT+IFEMYx3CqBGnCWlwYY4bVdXcUnsPkqsCWtL/TYoIO2IX3aE391QWTtWkOI6qF6uKFt1r3x4l95P4Fjhsw== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a05:6a00:8911:b0:68e:3053:14b9 with SMTP id hw17-20020a056a00891100b0068e305314b9mr1864932pfb.2.1700894177861; Fri, 24 Nov 2023 22:36:17 -0800 (PST) Date: Sat, 25 Nov 2023 06:36:16 +0000 In-Reply-To: <20231123193937.11628-3-ddrokosov@salutedevices.com> Mime-Version: 1.0 References: <20231123193937.11628-1-ddrokosov@salutedevices.com> <20231123193937.11628-3-ddrokosov@salutedevices.com> Message-ID: <20231125063616.dex3kh3ea43ceyu3@google.com> Subject: Re: [PATCH v3 2/2] mm: memcg: introduce new event to trace shrink_memcg From: Shakeel Butt To: Dmitry Rokosov Cc: rostedt@goodmis.org, mhiramat@kernel.org, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, muchun.song@linux.dev, mhocko@suse.com, akpm@linux-foundation.org, kernel@sberdevices.ru, rockosov@gmail.com, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 2D053140009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gkyr1f63yi9gyebgic19f1ix18ptikqd X-HE-Tag: 1700894178-253528 X-HE-Meta: U2FsdGVkX1930V+Pb8AAao0sKyEfhhN/u/ZQ8+Ahga8OG+MGiC6C4kiETivQU1LyoFTbu4vagqCl2rWefT51EvngDFdVqhWo712nfFT98vzWqUHIlR03dYlPeNM5kplhBcu4fomWE0kOUS8mKvFi1+u0I0bUizfrMIOjK5LBfFpHtfZQVg1FoDI2uJbFZuh9Imd6RqjbNAdPUmfkkkMqugt34m0MqQmIQMsOkN6zuZdAVPJK0/3A5hAXsWYvTKMuCExFvLLuj3EO4XPZTEsxxekDgsaHx3NqBQJQl+jb/Xierj6Ue1L8xZ2q0EBy3+8gCvgTcU4b+B1++0ntLDvuCS4eZoRB8kl2x7nhnnkiJepHB7kiFg89Cq6VTr+Snq4rtwuS7BuOZ6uKMnqdkKvbrmx5T0UwrSFNW4xAGdbaGSXV9Y9rD9exgF7vCWyOOpm9uP3WJk3qcl2sIEX5rm4aHMz7IFbzV1sma/7qxqcc3le3UpnltruxtEpVVxaTL6Cx1VoW8RNmXl9w0V6dQ3bdQ6bjn7MZYufFfvXzdIbUzNICEWIYlYtfL/HG+YqI7Lc1/xPHVSuKkjrIWSSSCoD6xHR/rqTXR44TggiZptrp/4V7fkLPxHysY/3TKYBCxvIzy18gYinp5MviATSdqv8FMjZihgmQa9gaJ6KxW+B53u6CE4hvdumhBfvZGDvtICwFFsk0PnX6MNYDywsAmNwQzUOlOW76MPQEJmxEaqgaMUqSHBYOt8zUJz4uk63iGTgdFgdC6H2KnE5pt1s0NWEKLOx5aRETTO2+eKy95+o3PVm8ykA2LZZxk6z7q4qIBirEwHLtjGxCH7qbu5Z+Xi5NmKF0Ixaqjf5cZaSBJGBz64sEbnb8XS63nJ4rh6MoreqtTSvjQCcSrC2YIF7oDZXVRZlpWzLkCNs/zt4utjvhcf8tzJQzlLq0k6O95KdI0kKsNPk2xaf3FlXH4aXxtXW R4QJmh8Y 0pKdCK03G6nnCtzRFXjRjZXsS7EldeqGpdQU4pNitdyDlVSdBAK9M/XRRndFXVv+zsp12nbKNYZ/kw0ooj0xDz5DF9rtAJrV1d0LHgVJ1uHtbcjtxmCpaZ7szczGHMdBFrReF3lL1+zOAuqzTFLSsd5DysRy0pkGXEyKuP4+I9PQqG8ghd7Pvbgy7ELhc77HsNAA//deJ2njbedALI4lc5V4L6t79RjJ70GVbUARul7a0HMXfp9ZLc4G1IyttoUqwDCU30G45DBdYvx5/tieuSmPcnwkYbFpCb+xmPpJ+agRVuqTuafT6t5UIhBhCV/QKRFkwrjc70suDOBYA5Uj6JOimhkvy87zpuYQiwBVPNMCMVi+dbBE7pnNWv2wD6+L99iAi6Gi8FeZkmh67s8aNlBCOJX35Ou71ERUwEZYdt2CwcNAl0uw/DHnYCuNHJw8tCKZS5ThfWTsi13OsPbEcZD2WheVfPMeGbc2H/RctJc1InkW5TV/UD3xxhs7txMUU4didwSL69Xo4Ebu90nEk501IrbPeLVyQCLXRA+USvBQohJVvtefS6EzsKsxLYg34ud/aBPwc/foLev7YpObzP2J84DtFM9/3kYmjpYS8/H/GtFCFZLIEo1R110+LCbvTY1OUAccWvOs+AABN+bqDC3vRQL/UsaHJZIrQEQcPzS3zNK8llQwV9sfUR0/76LnrdmhDyAysF9jujEk+g32FZ568sQ== 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 Thu, Nov 23, 2023 at 10:39:37PM +0300, Dmitry Rokosov wrote: > The shrink_memcg flow plays a crucial role in memcg reclamation. > Currently, it is not possible to trace this point from non-direct > reclaim paths. However, direct reclaim has its own tracepoint, so there > is no issue there. In certain cases, when debugging memcg pressure, > developers may need to identify all potential requests for memcg > reclamation including kswapd(). The patchset introduces the tracepoints > mm_vmscan_memcg_shrink_{begin|end}() to address this problem. > > Example of output in the kswapd context (non-direct reclaim): > kswapd0-39 [001] ..... 240.356378: mm_vmscan_memcg_shrink_begin: order=0 gfp_flags=GFP_KERNEL memcg=16 > kswapd0-39 [001] ..... 240.356396: mm_vmscan_memcg_shrink_end: nr_reclaimed=0 memcg=16 > kswapd0-39 [001] ..... 240.356420: mm_vmscan_memcg_shrink_begin: order=0 gfp_flags=GFP_KERNEL memcg=16 > kswapd0-39 [001] ..... 240.356454: mm_vmscan_memcg_shrink_end: nr_reclaimed=1 memcg=16 > kswapd0-39 [001] ..... 240.356479: mm_vmscan_memcg_shrink_begin: order=0 gfp_flags=GFP_KERNEL memcg=16 > kswapd0-39 [001] ..... 240.356506: mm_vmscan_memcg_shrink_end: nr_reclaimed=4 memcg=16 > kswapd0-39 [001] ..... 240.356525: mm_vmscan_memcg_shrink_begin: order=0 gfp_flags=GFP_KERNEL memcg=16 > kswapd0-39 [001] ..... 240.356593: mm_vmscan_memcg_shrink_end: nr_reclaimed=11 memcg=16 > kswapd0-39 [001] ..... 240.356614: mm_vmscan_memcg_shrink_begin: order=0 gfp_flags=GFP_KERNEL memcg=16 > kswapd0-39 [001] ..... 240.356738: mm_vmscan_memcg_shrink_end: nr_reclaimed=25 memcg=16 > kswapd0-39 [001] ..... 240.356790: mm_vmscan_memcg_shrink_begin: order=0 gfp_flags=GFP_KERNEL memcg=16 > kswapd0-39 [001] ..... 240.357125: mm_vmscan_memcg_shrink_end: nr_reclaimed=53 memcg=16 > > Signed-off-by: Dmitry Rokosov > --- > include/trace/events/vmscan.h | 22 ++++++++++++++++++++++ > mm/vmscan.c | 7 +++++++ > 2 files changed, 29 insertions(+) > > diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h > index e9093fa1c924..a4686afe571d 100644 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -180,6 +180,17 @@ DEFINE_EVENT(mm_vmscan_memcg_reclaim_begin_template, mm_vmscan_memcg_softlimit_r > TP_ARGS(order, gfp_flags, memcg) > ); > > +DEFINE_EVENT(mm_vmscan_memcg_reclaim_begin_template, mm_vmscan_memcg_shrink_begin, > + > + TP_PROTO(int order, gfp_t gfp_flags, const struct mem_cgroup *memcg), > + > + TP_ARGS(order, gfp_flags, memcg) > +); > + > +#else > + > +#define trace_mm_vmscan_memcg_shrink_begin(...) > + > #endif /* CONFIG_MEMCG */ > > DECLARE_EVENT_CLASS(mm_vmscan_direct_reclaim_end_template, > @@ -243,6 +254,17 @@ DEFINE_EVENT(mm_vmscan_memcg_reclaim_end_template, mm_vmscan_memcg_softlimit_rec > TP_ARGS(nr_reclaimed, memcg) > ); > > +DEFINE_EVENT(mm_vmscan_memcg_reclaim_end_template, mm_vmscan_memcg_shrink_end, > + > + TP_PROTO(unsigned long nr_reclaimed, const struct mem_cgroup *memcg), > + > + TP_ARGS(nr_reclaimed, memcg) > +); > + > +#else > + > +#define trace_mm_vmscan_memcg_shrink_end(...) > + > #endif /* CONFIG_MEMCG */ > > TRACE_EVENT(mm_shrink_slab_start, > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 45780952f4b5..f7e3ddc5a7ad 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -6461,6 +6461,10 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) > */ > cond_resched(); > > + trace_mm_vmscan_memcg_shrink_begin(sc->order, > + sc->gfp_mask, > + memcg); > + If you place the start of the trace here, you may have only the begin trace for memcgs whose usage are below their min or low limits. Is that fine? Otherwise you can put it just before shrink_lruvec() call. > mem_cgroup_calculate_protection(target_memcg, memcg); > > if (mem_cgroup_below_min(target_memcg, memcg)) { > @@ -6491,6 +6495,9 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) > shrink_slab(sc->gfp_mask, pgdat->node_id, memcg, > sc->priority); > > + trace_mm_vmscan_memcg_shrink_end(sc->nr_reclaimed - reclaimed, > + memcg); > + > /* Record the group's reclaim efficiency */ > if (!sc->proactive) > vmpressure(sc->gfp_mask, memcg, false, > -- > 2.36.0 >