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 4FFADC4167B for ; Mon, 27 Nov 2023 12:50:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DC2E6B02EF; Mon, 27 Nov 2023 07:50:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 98C086B02F0; Mon, 27 Nov 2023 07:50:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 853A26B02F1; Mon, 27 Nov 2023 07:50:27 -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 747C96B02EF for ; Mon, 27 Nov 2023 07:50:27 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4A0E9B55BA for ; Mon, 27 Nov 2023 12:50:27 +0000 (UTC) X-FDA: 81503717694.08.A89DB18 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf20.hostedemail.com (Postfix) with ESMTP id 0106C1C001D for ; Mon, 27 Nov 2023 12:50:24 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701089425; 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; bh=A1cp3yyuimZ+7cAqIyofRmJaM2fva8rXS+LudG+2Zg4=; b=dH+9oCesG9bqGg4qLaOEH1pPcheMHKrRgx51sjBjP7jzxmrzvFuuIxuhjvXS0kebsoeujd fe4OGA0k21LMzpgAEyvPHHVBr0NJSiFdDGc6Kw6O4225jPBEZ3l5fHM0DyjxjFv+B+Tiew YlKnGbQNvqKD+iEHOImj3NLaH9OisFE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701089425; a=rsa-sha256; cv=none; b=y+lK10chmYHXXOc9r1mxG81C210tccryH1dvGDHxXsj/zwwPh1iOYWjRU4EZhcxYDukedy nxjzbWCD7i5arTmaxC2C+HWgG4J+AujSuxYChmYw/Dkf0/y49enZmLeqATU9ZtiB02ExxM TgqBioFKluS7fFHAI86SHFkWlJhHgn4= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id D68A720329; Mon, 27 Nov 2023 12:50:22 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C9A661367B; Mon, 27 Nov 2023 12:50:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id mmA2MY6QZGWIBgAAD6G6ig (envelope-from ); Mon, 27 Nov 2023 12:50:22 +0000 Date: Mon, 27 Nov 2023 13:50:22 +0100 From: Michal Hocko To: Dmitry Rokosov Cc: rostedt@goodmis.org, mhiramat@kernel.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, 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 Subject: Re: [PATCH v3 2/2] mm: memcg: introduce new event to trace shrink_memcg Message-ID: References: <20231123193937.11628-1-ddrokosov@salutedevices.com> <20231123193937.11628-3-ddrokosov@salutedevices.com> <20231127113644.btg2xrcpjhq4cdgu@CAB-WSD-L081021> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231127113644.btg2xrcpjhq4cdgu@CAB-WSD-L081021> X-Spamd-Bar: +++++++++++++++ X-Spam: Yes X-Rspamd-Queue-Id: 0106C1C001D X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: u379xs7tj1pimfuygtnaszssx99ppwu7 X-HE-Tag: 1701089424-626909 X-HE-Meta: U2FsdGVkX1+3y9kJllwB8jKLYB8WXNQg6TTNTmdywNJpkqnJLhv4+R3UolZlhcEqaUFYHSY8b36UkcF4Ca3vagWVjcvHFhtY7Qi8uO6oUHCM1du0w81MHvBBJA7HRf+TITm63S7L76kSopZZjNUAhb/29FOOREvyfSqeMmSqoUCbeR9baAK7paeOv4pjCzDpgjA4WTykqGJ4jkrRF4hpRoYvbjOfNhPwMa6Uys9l/ui9fzR/gg9pH+Yuwy8pMDpZOecOTEYp5XIKLarOhW3UhJnhNrlwZIFtBMmMcshCDt8fv962MtNDqS6JUQKlTOnlYR1UUEjDFO9zRVi/7/COcnh6sok3/SvgZ53ilHbY2YO4Z6qG8AarRDPUONVVdZXlXgDoOxMiIhCiiEBrO+nbqKionNpVIkLtWpVVLE3CnoSKzRS4P36PfXMUA2/gzWqCXDBhXqpoDHYncKLk+3/CkiXTe4BZVgite4VKZaNUc7g7u+hb4/dTx1qeeSBuyOI0U4GXJlUlA5cSI76oR3y8yz9UZxT0Nd4SSKoRLueMiDhNhRqWD1895bCZGx1MWHkHb11K9ckCHLUcPTOpyDPd0Cjy27la/tGETnBCOpxXVXL2kYimFhAGSqrIt51vJk6GyKr7nC1FrTyQE/OZDaj2I2hsNc9bqkEv1RXSQPlEYhWDl0nVgvh2VjZbAjn6E2bAqP4q42pu09/ikd4TOkbZKL6Mop4vARG7V4yeJrss06+4RKNhuVaCO0Y+hyMWrJ5UBUCqmF1kafqyTY5rhavp0FtDhHJrmcqqSoOjlOwSQc4WQbLmYHoEmnrer3oKvvrkX5MKlLOcACdrgXgaXhfb9yY8ZCeZ4zDhX47At/8Dre+E/cONvKEBstjCSoqi9v/J30RS9tktCD6ma6Mpuqx+40R/w5Tb92RaXkY3YTqTneKuy2mFZWHKAW++eBuwe49ca192rYs4sFbGirAx/O5 Jm67Zttn TdSbQj8X6LdHb619IagarQPJugiL6+6izrwYgtfgn+1FqibNzXd+yJto+604dtq6A3i+EQEcGkfs9lGqpEDMUkGhkOACF91loOrLPNbTXwWF7qwNdZ4ESijzXdSCKfhGT8Y/JnxLzTD/RpJIjnrUklICUaoaV3E56vd8qyxM0RoVmW5Yd3COl/spYHeXxj5U0bfPYT/R/EQ+NCgngoAx66mX5IHAPJzgxih4L 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 Mon 27-11-23 14:36:44, Dmitry Rokosov wrote: > On Mon, Nov 27, 2023 at 10:33:49AM +0100, Michal Hocko wrote: > > On Thu 23-11-23 22:39:37, 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 > > > > In the previous version I have asked why do we need this specific > > tracepoint when we already do have trace_mm_vmscan_lru_shrink_{in}active > > which already give you a very good insight. That includes the number of > > reclaimed pages but also more. I do see that we do not include memcg id > > of the reclaimed LRU, but that shouldn't be a big problem to add, no? > > >From my point of view, memcg reclaim includes two points: LRU shrink and > slab shrink, as mentioned in the vmscan.c file. > > > static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) > ... > reclaimed = sc->nr_reclaimed; > scanned = sc->nr_scanned; > > shrink_lruvec(lruvec, sc); > > shrink_slab(sc->gfp_mask, pgdat->node_id, memcg, > sc->priority); > ... > > So, both of these operations are important for understanding whether > memcg reclaiming was successful or not, as well as its effectiveness. I > believe it would be beneficial to summarize them, which is why I have > created new tracepoints. This sounds like nice to have rather than must. Put it differently. If you make existing reclaim trace points memcg aware (print memcg id) then what prevents you from making analysis you need? -- Michal Hocko SUSE Labs