Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp4724759rdh; Wed, 29 Nov 2023 08:58:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IGYmBd0+wwoUFn72A/9o8VyTX/MOhs4q4lCS2GJxrz9Mote+DdomStC3v9P1H+jJQK9Ran0 X-Received: by 2002:a17:902:d50e:b0:1cf:c518:fa3f with SMTP id b14-20020a170902d50e00b001cfc518fa3fmr12184863plg.35.1701277128724; Wed, 29 Nov 2023 08:58:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701277128; cv=none; d=google.com; s=arc-20160816; b=m1LriajnNYdpEOyIpntfFrnzcgSRzYfMuK65v4Gb0ob2/ETHZZSvdb5CndJlFlpBFg quRRSRQqFTH7bd87ucl/qC+Ads/jo5XEIGf33qCP8DJynYd+8AKbD3AKEK+yfZjt3U/s d67zZ1pTJ+1HdW9usOu+rk1VNxfzbnTJRVekCT3VVlVpjiS6/N/YR4Y+sdfIH9zOKW25 3hGsAeGAMTv4GPneDUu7IFs2tl2r6L6GL/JE2p+0UAkNe9xK+GPpVaiH9QquM6dLQEYH hf/DAe1Es07oRBmd32N34n+BRY5gVek535Ex7rCu1you64vsXl75IS07aBMhQXTa+Qku khvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-filter; bh=upFUqpfrDquVThehPQDeK2Tu8Ir/v12aprC4JpKU8g8=; fh=PKD5P51ivJK6fko55OaFL7dHeZoQh5O7An3Z2hS/Jl0=; b=CV9D2/oWQjMBqqEWH08Yreu+dOzh92QGtjqYtGU+5NBnmKAp75G7/Q8Qi2lnCcxjTd c+UMA9k/443xnntab58mqPehINf10RaLFd18rrwERDowiF3KMQlKeNrQf9JPfs+Ew9Dc CRusnTi5Q/arxGkIhXFofMXvPOXZsqHOJi4attdC5i8UxnDJtwwEau3VJDA/UXD43EPH Ebvgi5YWgjM/fOKNT+fg441N+xM2Rl0qNkmPnjN5/rmJHzk3oNyztfsfdmT2XcnxPlhG roaHTh3oXlGMuaFgAA+sIr5IArM/N4G9qUJ0NHaoE9PkkJm76Q3OgXVf7zSAcXOmS3hk vhWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@salutedevices.com header.s=mail header.b=QyEeJHDy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=salutedevices.com Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id h6-20020a170902f54600b001cfcd4d8f41si5367316plf.136.2023.11.29.08.58.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Nov 2023 08:58:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@salutedevices.com header.s=mail header.b=QyEeJHDy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=salutedevices.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 4B72D8084072; Wed, 29 Nov 2023 08:58:45 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233681AbjK2Q60 (ORCPT + 99 others); Wed, 29 Nov 2023 11:58:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233878AbjK2Q6H (ORCPT ); Wed, 29 Nov 2023 11:58:07 -0500 Received: from mx1.sberdevices.ru (mx2.sberdevices.ru [45.89.224.132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B670D6E; Wed, 29 Nov 2023 08:57:55 -0800 (PST) Received: from p-infra-ksmg-sc-msk02 (localhost [127.0.0.1]) by mx1.sberdevices.ru (Postfix) with ESMTP id D921512000B; Wed, 29 Nov 2023 19:57:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.sberdevices.ru D921512000B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salutedevices.com; s=mail; t=1701277072; bh=upFUqpfrDquVThehPQDeK2Tu8Ir/v12aprC4JpKU8g8=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:From; b=QyEeJHDyMXu3Q+rlfWn4C2wnOcfgs5R9+/8V5/w7GE8JbjSqUchhlkwfgYa8X7vt0 QU5j3vJciChTqH9yqdDdTyhBzZhWl2sfX4f3UNBrSLnt0woaXc/i9ISrlj5i7Yk1gu VuB+0bZjvyEowbIpCyi8Ghq8X+I1diR+JfYzzv5Xaz4BUBMehQZbDR6iFPfUwRK2U2 5xYjvU7x/If4jFf7xqkvQ8ROrC8Z61gdDhTskFDJhEt2zuztgu4xto9WND+WOSqwPP qoaRD5b22jczH3m5D0MqzXw8IB196L7wEx/ia6A8QM1OqfOGEMvAjZ065aZOHBEKXd YGaRAbUe7ZaGQ== 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, 29 Nov 2023 19:57:52 +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, 29 Nov 2023 19:57:52 +0300 Date: Wed, 29 Nov 2023 19:57:52 +0300 From: Dmitry Rokosov To: Michal Hocko , CC: , , , , , , , , , , , , Subject: Re: [PATCH v3 2/2] mm: memcg: introduce new event to trace shrink_memcg Message-ID: <20231129165752.7r4o3jylbxrj7inb@CAB-WSD-L081021> References: <20231123193937.11628-1-ddrokosov@salutedevices.com> <20231123193937.11628-3-ddrokosov@salutedevices.com> <20231127113644.btg2xrcpjhq4cdgu@CAB-WSD-L081021> <20231127161637.5eqxk7xjhhyr5tj4@CAB-WSD-L081021> <20231129152057.x7fhbcvwtsmkbdpb@CAB-WSD-L081021> 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: 181706 [Nov 29 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: 5 0.3.5 98d108ddd984cca1d7e65e595eac546a62b0144b, {Track_E25351}, {Tracking_from_domain_doesnt_match_to}, d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;p-i-exch-sc-m01.sberdevices.ru:5.0.1,7.1.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/29 12:04:00 #22572143 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 29 Nov 2023 08:58:45 -0800 (PST) On Wed, Nov 29, 2023 at 05:06:37PM +0100, Michal Hocko wrote: > On Wed 29-11-23 18:20:57, Dmitry Rokosov wrote: > > On Tue, Nov 28, 2023 at 10:32:50AM +0100, Michal Hocko wrote: > > > On Mon 27-11-23 19:16:37, Dmitry Rokosov wrote: > [...] > > > > 2) With this approach, we will not have the ability to trace a situation > > > > where the kernel is requesting reclaim for a specific memcg, but due to > > > > limits issues, we are unable to run it. > > > > > > I do not follow. Could you be more specific please? > > > > > > > I'm referring to a situation where kswapd() or another kernel mm code > > requests some reclaim pages from memcg, but memcg rejects it due to > > limits checkers. This occurs in the shrink_node_memcgs() function. > > Ohh, you mean reclaim protection > > > === > > mem_cgroup_calculate_protection(target_memcg, memcg); > > > > if (mem_cgroup_below_min(target_memcg, memcg)) { > > /* > > * Hard protection. > > * If there is no reclaimable memory, OOM. > > */ > > continue; > > } else if (mem_cgroup_below_low(target_memcg, memcg)) { > > /* > > * Soft protection. > > * Respect the protection only as long as > > * there is an unprotected supply > > * of reclaimable memory from other cgroups. > > */ > > if (!sc->memcg_low_reclaim) { > > sc->memcg_low_skipped = 1; > > continue; > > } > > memcg_memory_event(memcg, MEMCG_LOW); > > } > > === > > > > With separate shrink begin()/end() tracepoints we can detect such > > problem. > > How? You are only reporting the number of reclaimed pages and no > reclaimed pages could be not just because of low/min limits but > generally because of other reasons. You would need to report also the > number of scanned/isolated pages. > From my perspective, if memory control group (memcg) protection restrictions occur, we can identify them by the absence of the end() pair of begin(). Other reasons will have both tracepoints raised. > > > > 3) LRU and SLAB shrinkers are too common places to handle memcg-related > > > > tasks. Additionally, memcg can be disabled in the kernel configuration. > > > > > > Right. This could be all hidden in the tracing code. You simply do not > > > print memcg id when the controller is disabled. Or just simply print 0. > > > I do not really see any major problems with that. > > > > > > I would really prefer to focus on that direction rather than adding > > > another begin/end tracepoint which overalaps with existing begin/end > > > traces and provides much more limited information because I would bet we > > > will have somebody complaining that mere nr_reclaimed is not sufficient. > > > > Okay, I will try to prepare a new patch version with memcg printing from > > lruvec and slab tracepoints. > > > > Then Andrew should drop the previous patchsets, I suppose. Please advise > > on the correct workflow steps here. > > Andrew usually just drops the patch from his tree and it will disappaer > from the linux-next as well. Okay, I understand, thank you! Andrew, could you please take a look? I am planning to prepare a new patch version based on Michal's suggestion, so previous one should be dropped. -- Thank you, Dmitry