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 9609EC433FE for ; Tue, 1 Feb 2022 10:49:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB50D6B0191; Tue, 1 Feb 2022 05:49:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A64126B0192; Tue, 1 Feb 2022 05:49:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9531C6B0193; Tue, 1 Feb 2022 05:49:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 859256B0191 for ; Tue, 1 Feb 2022 05:49:14 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 41D5398C00 for ; Tue, 1 Feb 2022 10:49:14 +0000 (UTC) X-FDA: 79093889028.24.3B82825 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf28.hostedemail.com (Postfix) with ESMTP id BE917C0005 for ; Tue, 1 Feb 2022 10:49:13 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 320331F397; Tue, 1 Feb 2022 10:49:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1643712552; 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=l6Bn0nz2rnpcXkXYw/gRthu/0RqSHCGbN5yIH2/zMno=; b=LsrFLxhXhW9MQ5itj+U/rbYQQCU2+RZgxSgqRPFPCH62iHD/1uuU1u+XTeTmuwRN7c3vBl 7xp0WzHh84RoSxn0EONv306e8MJ1H89YhCsuKp+FnGzVoE92rGb1n/4pI20rWUQi1J/SmO giL7UgDUxBg/dDgNhnO46MAaplPB8qo= 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 C1067A3B84; Tue, 1 Feb 2022 10:49:11 +0000 (UTC) Date: Tue, 1 Feb 2022 11:49:11 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12686956-612d-d89b-5641-470d5e913090@redhat.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BE917C0005 X-Stat-Signature: jahkpomehxzxp9wy3px91kyrczq67wfj Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LsrFLxhX; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.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: 1643712553-560689 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 Mon 31-01-22 13:38:28, Waiman Long wrote: [...] > Of course, it is also possible to have a debugfs interface to list those > dead memcg information, displaying more information about the page that pins > the memcg will be hard without using the page owner tool. Yes, you will need page owner or hook into the kernel by other means (like already mentioned drgn). The question is whether scanning all existing pages to get that information is the best we can offer. > Keeping track of > the list of dead memcg's may also have some runtime overhead. 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. -- Michal Hocko SUSE Labs