Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2417155pxb; Thu, 3 Feb 2022 06:17:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJxjtJJNJh0rJmrl1QhqQH/CrOryUSQfBrbWF3UyrfjY4SHOpkA5AH/RdY/lwbRBMyCqZR1k X-Received: by 2002:a17:902:714c:: with SMTP id u12mr35883683plm.51.1643897863061; Thu, 03 Feb 2022 06:17:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643897863; cv=none; d=google.com; s=arc-20160816; b=qpBT0R6q+3zvTz6lM7lxcBcMLZ02+7ArXYryDuV6zaJ4wBihUhNYlPYqptbwTiAD8k 7PldeMCaGY2plh1skyp2s6C8Fd05hUE3KhbvXJcTlm+MSRGzbG1z2E+MgChjMIL5xIX5 ZdcpTZOpeN4RWFtNZPSbyrQ3Eg85c4iqRbGOssLEXh9ZZRU5gz5chlTYXYc+gwR0avLD tdys5NqG+5y+9ZJx00BQItFcfeRQ91XWGwfHz9uTLnPQ5eeBWH5kC4uNwI2WqlDOEupy xmlqg53IA1C8gcfY7pDVsVdM1P2Z6nGrk3pcFQmDj5lxMMFTgQipGeFDJTf5kQNNvLHY BeGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=QOGbA/DaSksq8t2y0SLaZx5K3xyXpnf22hXltgoj2Fw=; b=TAQwmtiqR+iYFgA7ybrkEgIHntn81moccBvvBMSLcZw5VLM8j8jAshHYSVR3DGRz+0 5ySicMCQ15ePUJyxwyWEJrjfXDYsmN753WTvMMoYsgIfN8SxngCG1tvIWIm5mkxwPbzc lydHKXYEQy8MQA1cak9Mgj37P3/Jvo1nybDefz5lB7tucoAe3Askk5VWVoIYX0CmtWuq NG/PcpAaK0cMO1wzo6Ze3TNTZCaSD7ajXsKLiYRq+sqpdMZfszWCUcVgNkodLV73v9SB 0TPv9Mix1kgL3vPI/d57jziqOCtCmhUEUyPtjKEy4Fa80T3PtBxPXmlxh6O640k05sRz Pk7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=LhIA8sT2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u10si27414330plg.209.2022.02.03.06.17.28; Thu, 03 Feb 2022 06:17:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=LhIA8sT2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244489AbiBBI51 (ORCPT + 99 others); Wed, 2 Feb 2022 03:57:27 -0500 Received: from smtp-out2.suse.de ([195.135.220.29]:54608 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243815AbiBBI5V (ORCPT ); Wed, 2 Feb 2022 03:57:21 -0500 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 0FDE81F387; Wed, 2 Feb 2022 08:57:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1643792240; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QOGbA/DaSksq8t2y0SLaZx5K3xyXpnf22hXltgoj2Fw=; b=LhIA8sT2rPTk+xUTfSOMbKqiw1YaHgL8WEvnQwQaE8RIgfTuF/oXaok7rVxYr0eUm76gBP tKyng2cUPZgMaUOiqK8zidjTdW8C7kUiKGcNLcL90ROT7Ii18MOlOGjx+CAeJelgXdv8+e cjOjfdIQM3+Ukl0p0BaZAyyeolcVVso= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id D40DFA3B8C; Wed, 2 Feb 2022 08:57:19 +0000 (UTC) Date: Wed, 2 Feb 2022 09:57:18 +0100 From: Michal Hocko To: Waiman Long Cc: Roman Gushchin , Johannes Weiner , Vladimir Davydov , Andrew Morton , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Ira Weiny , Rafael Aquini Subject: Re: [PATCH v2 3/3] mm/page_owner: Dump memcg information Message-ID: References: <20220129205315.478628-1-longman@redhat.com> <20220129205315.478628-4-longman@redhat.com> <12686956-612d-d89b-5641-470d5e913090@redhat.com> <268a8bdf-4c70-b967-f34c-2293b54186f0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <268a8bdf-4c70-b967-f34c-2293b54186f0@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 01-02-22 11:41:19, Waiman Long wrote: > > On 2/1/22 05:49, Michal Hocko wrote: [...] > > Could you be more specific? Offlined memcgs are still part of the > > hierarchy IIRC. So it shouldn't be much more than iterating the whole > > cgroup tree and collect interesting data about dead cgroups. > > What I mean is that without piggybacking on top of page_owner, we will to > add a lot more code to collect and display those information which may have > some overhead of its own. Yes, there is nothing like a free lunch. Page owner is certainly a tool that can be used. My main concern is that this tool doesn't really scale on large machines with a lots of memory. It will provide a very detailed information but I am not sure this is particularly helpful to most admins (why should people process tons of allocation backtraces in the first place). Wouldn't it be sufficient to have per dead memcg stats to see where the memory sits? Accumulated offline memcgs is something that bothers more people and I am really wondering whether we can do more for those people to evaluate the current state. -- Michal Hocko SUSE Labs