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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70C4AC433EF for ; Wed, 2 Feb 2022 08:57:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245271AbiBBI53 (ORCPT ); Wed, 2 Feb 2022 03:57:29 -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