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 6B53BC433F5 for ; Wed, 2 Feb 2022 08:57:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8ADB8D00F5; Wed, 2 Feb 2022 03:57:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C3B148D00C9; Wed, 2 Feb 2022 03:57:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B02288D00F5; Wed, 2 Feb 2022 03:57:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 9CDBD8D00C9 for ; Wed, 2 Feb 2022 03:57:22 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 503A795CAA for ; Wed, 2 Feb 2022 08:57:22 +0000 (UTC) X-FDA: 79097235924.21.9E47490 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf01.hostedemail.com (Postfix) with ESMTP id DD9AF40003 for ; Wed, 2 Feb 2022 08:57:21 +0000 (UTC) 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> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: DD9AF40003 X-Stat-Signature: 64awzrr7xyazbq7p7he37xygq5eyxmgz Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LhIA8sT2; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspam-User: nil X-HE-Tag: 1643792241-342272 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: 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