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 A6EC2C61D9B for ; Wed, 22 Nov 2023 10:58:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DE218D002C; Wed, 22 Nov 2023 05:58:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 38C528D0008; Wed, 22 Nov 2023 05:58:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1ECFF8D002C; Wed, 22 Nov 2023 05:58:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 077128D0008 for ; Wed, 22 Nov 2023 05:58:42 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D4CAA1CB1D4 for ; Wed, 22 Nov 2023 10:58:41 +0000 (UTC) X-FDA: 81485292042.28.9A433BD Received: from mx1.sberdevices.ru (mx2.sberdevices.ru [45.89.224.132]) by imf19.hostedemail.com (Postfix) with ESMTP id 78E011A000C for ; Wed, 22 Nov 2023 10:58:38 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=salutedevices.com header.s=mail header.b=G84a0EFV; spf=pass (imf19.hostedemail.com: domain of ddrokosov@salutedevices.com designates 45.89.224.132 as permitted sender) smtp.mailfrom=ddrokosov@salutedevices.com; dmarc=pass (policy=quarantine) header.from=salutedevices.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700650719; 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=zFx+5dXlR2EQJnObSWY+xM9oMXFlaTN9St5MLae6TwM=; b=z7lkDSgZ7JF9RdE+msorCK2YBUmtz+U+vV9U+PyhVPi+4HFytYHZ0I7J/QkSwF86TMX7aS LPZ5XxZkQ5SISRF3R9HGKEawr37Q1dsxWev80sgO3vhRdMwUZV5mPP+57vhVQk94y2cBmz 6IIwt7ecmYkwBAlHmnLDoxxHUwkOEo0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700650719; a=rsa-sha256; cv=none; b=lgjSYlTBCevCyy0KiW8PjPLSToQecARWwfWIcD6xhvl7GPJ19tEIz9Mlk230FDn5qN4K8A 6/3T9KWrEtL+NZKnq/v371Y2I0T2uluwlLrotou7Jn1oFnjQ94Yrn/SwC6t7ovxygvrMf2 Ba7MxW2txL9KbJWDbkoyitNT3ndeZag= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=salutedevices.com header.s=mail header.b=G84a0EFV; spf=pass (imf19.hostedemail.com: domain of ddrokosov@salutedevices.com designates 45.89.224.132 as permitted sender) smtp.mailfrom=ddrokosov@salutedevices.com; dmarc=pass (policy=quarantine) header.from=salutedevices.com Received: from p-infra-ksmg-sc-msk02 (localhost [127.0.0.1]) by mx1.sberdevices.ru (Postfix) with ESMTP id B645C120069; Wed, 22 Nov 2023 13:58:36 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.sberdevices.ru B645C120069 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salutedevices.com; s=mail; t=1700650716; bh=zFx+5dXlR2EQJnObSWY+xM9oMXFlaTN9St5MLae6TwM=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:From; b=G84a0EFVLTgDdOvzlXW6Mebu1TojgZDXRItdf9fVmFZptmL/l4AUVXhCOIcCS6MlY F3AlevIX7gjzhw4tHFR/HPMzOyEWKhNnpdWCqD4bFODqBbEoGdNOZKnrzzdKpdoAnU L7G/cZEMqghNyITCn6zr97jKaLuiz81Xlf3bWFkBQTyZrN0eOju9xmwfXbrASCzCF/ id2MaU/PYACpREAf8Lvad1T8JfY3/Z/SDHdOBupzg2wLKLbfXzbiHVf/wFrHoHhE/I l7irZapLjznCc0Uxpi6nfeX3qRnSjOXyJsRfpbkOvhFOkXwVI4DnJgDbabHMWfPK9o E7iNEXuUIrLpA== Received: from p-i-exch-sc-m01.sberdevices.ru (p-i-exch-sc-m01.sberdevices.ru [172.16.192.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sberdevices.ru (Postfix) with ESMTPS; Wed, 22 Nov 2023 13:58:36 +0300 (MSK) Received: from localhost (100.64.160.123) by p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Wed, 22 Nov 2023 13:58:36 +0300 Date: Wed, 22 Nov 2023 13:58:36 +0300 From: Dmitry Rokosov To: Michal Hocko CC: , , , , , , , , , , , , Subject: Re: [PATCH v2 2/2] mm: memcg: introduce new event to trace shrink_memcg Message-ID: <20231122105836.xhlgbwmwjdwd3g5v@CAB-WSD-L081021> References: <20231122100156.6568-1-ddrokosov@salutedevices.com> <20231122100156.6568-3-ddrokosov@salutedevices.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20220415 X-Originating-IP: [100.64.160.123] X-ClientProxiedBy: p-i-exch-sc-m02.sberdevices.ru (172.16.192.103) To p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) X-KSMG-Rule-ID: 10 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 181528 [Nov 22 2023] X-KSMG-AntiSpam-Version: 6.0.0.2 X-KSMG-AntiSpam-Envelope-From: ddrokosov@salutedevices.com X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Auth: dkim=none X-KSMG-AntiSpam-Info: LuaCore: 3 0.3.3 e5c6a18a9a9bff0226d530c5b790210c0bd117c8, {Track_E25351}, {Tracking_from_domain_doesnt_match_to}, d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;p-i-exch-sc-m01.sberdevices.ru:7.1.1,5.0.1;salutedevices.com:7.1.1;100.64.160.123:7.1.2;127.0.0.199:7.1.2, FromAlignment: s, ApMailHostAddress: 100.64.160.123 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean X-KSMG-LinksScanning: Clean X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.0.1.6960, bases: 2023/11/22 09:18:00 #22500551 X-KSMG-AntiVirus-Status: Clean, skipped X-Stat-Signature: 6xapyy1eqh1aswmohitbxxp5643fd8g5 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 78E011A000C X-Rspam-User: X-HE-Tag: 1700650718-631695 X-HE-Meta: U2FsdGVkX19PevF3s8oP1Pk3zLyyx8hhKU9+76y9MAAY8MrA9SutaUlb6A1M2xVoe6615z1/os1EtAT5Ikq0JF5E69wpWRkriIEKiK4iMRvpS7Z/ZkTTKfY5SBsNvG+IjBH1XkubpPFZdF06oHzS7tesIgmHPb7C/2LwuyyL9SPhZGfGXFNw00elc2REFTujBbMAYMHpIJPHfHvfTvf984uVQp7piHkFwOxiCdFQA8NSFKg009ZK5kfqaQg7GFSQ5LTqZXbfRfqDIqNYGMniwxModiLdKmf/7Z345HfdtSu8FL+jZ4KnswsxxINTOzumtYynTN+91r3PbYaAVLYKfwTsRYtrnCHU3Gljx03IElJT6vdywKQ0RwHK4qoYhL8DOJFbziakJX/ScBMdBDvDxqju6OUXg1byFf47KNrN1lW79TB9ewxq73023YIb/HfjsccB3qzUh3p1DsF1kD5jRCp5IwcQwcl3nW3Tl6cP/T3PanpftJ/F8oon4+zP/weFz85+qBwtfEV+NWjaVkUnRLU0bxU+DqgTWByqpZmfOmOeRB/2qnLa/OZO/rTQfidzIH96Mxis3c+QKGEC77xZh4yYUM9Rh6Qlh35iN8I0i/kJTPapVN1XqnKckW6qYWy3evmgNyRS9PBKJbXtsNiY1gRfHsryHgPZjqz6RCSFJnZpQd5SG4spWNLhMgsdDOxROlhkGLf0WEWTqR/xqzOKNwu0cFP/PVuUCMLcZohCkh0CQQBiI5+b+oQyPubT06UNTVcLsjX1NrMVrxxEg/a6wqPvZXsADxY3js3falQvTBnwpxOgSPH89lbp8LcPL6/xdJ1LOfJsFyHyVJkzEkFLbn9Ihi4qJQ63WQmehGklUd1UNFfRSuioS3SdkYOSCC82hED0WvG6e9TM3h4f3IIkSO7847dR+2HFkvvYKNmkBmaXmYGkK4mUUjDYN3lgEW1g1++FRnQSdXh8YbucVeG uNYU7KDx 9emTaxKQa68yynS4nL+vu2osMvSqiNUEx2S7EoYTGwXpbO4Ib4udvVD+yU9I7/5Te/7VbN8YWITPmZosgTUP53LX44+quGtoA27ydCnNqjz954k2B41EGiWYkTYPLZTJrM/0X7uYwbDNabwjcAa4qpvSToD6EAeFO0dR03hwNdcrcv9SqIHBX5m5vRb3q7wdAKb7DmBtFZeMfU3RU27HOGl0Jeyul5kldmBwJRNdoN7rCcdBUTOYGVmEBsnnQPU6Vkz1qS7O+VG5KoI0Ui85AhrtyMoAQvoNSLQrBreZfnh7Q4poRuseKq/j78gzYtGebjWhFdMVrphNfQQxNECWZcJK2Q6vJD64gfDO39fa1KrY+zJSREuYMeVjNJONlIxXKk0suE6/xDVqd0+E= 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: Hello Michal, Thank you for the quick review! On Wed, Nov 22, 2023 at 11:23:24AM +0100, Michal Hocko wrote: > On Wed 22-11-23 13:01:56, 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. > > Is this really true? AFAICS we have > mm_vmscan_lru_isolate > mm_vmscan_lru_shrink_active > mm_vmscan_lru_shrink_inactive > > which are in the vry core of the memory reclaim. Sure post processing > those is some work. Sure, you are absolutely right. In the usual scenario, the memcg shrinker utilizes two sub-shrinkers: slab and LRU. We can enable the tracepoints you mentioned and analyze them. However, there is one potential issue. Enabling these tracepoints will trigger the reclaim events show for all pages. Although we can filter them per pid, we cannot filter them per cgroup. Nevertheless, there are times when it would be extremely beneficial to comprehend the effectiveness of the reclaim process within the relevant cgroup. For this reason, I am adding the cgroup name to the memcg tracepoints and implementing a cumulative tracepoint for memcg shrink (LRU + slab)." > > [...] > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 45780952f4b5..6d89b39d9a91 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -6461,6 +6461,12 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) > > */ > > cond_resched(); > > > > +#ifdef CONFIG_MEMCG > > + trace_mm_vmscan_memcg_shrink_begin(sc->order, > > + sc->gfp_mask, > > + memcg); > > +#endif > > this is a common code path for node and direct reclaim which means that > we will have multiple begin/end tracepoints covering similar operations. > To me that sounds excessive. If you are missing a cumulative kswapd > alternative to > mm_vmscan_direct_reclaim_begin > mm_vmscan_direct_reclaim_end > mm_vmscan_memcg_reclaim_begin > mm_vmscan_memcg_reclaim_end > mm_vmscan_memcg_softlimit_reclaim_begin > mm_vmscan_memcg_softlimit_reclaim_end > mm_vmscan_node_reclaim_begin > mm_vmscan_node_reclaim_end > > then place it into kswapd path. But it would be really great to > elaborate some more why this is really needed. Cannot you simply > aggregate stats for kswapd from existing tracepoints? > > -- > Michal Hocko > SUSE Labs -- Thank you, Dmitry