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 CA945C433F5 for ; Tue, 1 Feb 2022 16:41:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 073928D0073; Tue, 1 Feb 2022 11:41:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0239D8D006D; Tue, 1 Feb 2022 11:41:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E06648D0073; Tue, 1 Feb 2022 11:41:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id D0F288D006D for ; Tue, 1 Feb 2022 11:41:28 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8942C93D97 for ; Tue, 1 Feb 2022 16:41:28 +0000 (UTC) X-FDA: 79094776656.06.63CFE08 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf03.hostedemail.com (Postfix) with ESMTP id AEF5E20005 for ; Tue, 1 Feb 2022 16:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643733687; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PC8NZ8lG/hbKxyQngU3kWuHlJ5Tl5ht+lJl5+tMvXcM=; b=B7hNIJLRf1rknpzQE3GYo2p6w/JVO5Gl7gLZ355ox5uncd+RTUsnfsqQsWhXMVx6gUlYQ8 LTGaiG5+tufi9/5kYjuSgTGAS9Kq/2/Vw6gAMXKAyQ85dtabgs6Y76sGjRcd3VdKzXaBbu qvsU9Jr/tlMahM7HCVb3E1Q3SwH4o04= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-655-XeNOkZiYNrC9gA6ixD_JFQ-1; Tue, 01 Feb 2022 11:41:24 -0500 X-MC-Unique: XeNOkZiYNrC9gA6ixD_JFQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E95D41898292; Tue, 1 Feb 2022 16:41:21 +0000 (UTC) Received: from [10.22.19.61] (unknown [10.22.19.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id F14C410A4B53; Tue, 1 Feb 2022 16:41:19 +0000 (UTC) Message-ID: <268a8bdf-4c70-b967-f34c-2293b54186f0@redhat.com> Date: Tue, 1 Feb 2022 11:41:19 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v2 3/3] mm/page_owner: Dump memcg information Content-Language: en-US To: Michal Hocko 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 References: <20220129205315.478628-1-longman@redhat.com> <20220129205315.478628-4-longman@redhat.com> <12686956-612d-d89b-5641-470d5e913090@redhat.com> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AEF5E20005 X-Stat-Signature: ooqyau8t58587yjcqqwukpqgckw3psak Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=B7hNIJLR; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf03.hostedemail.com: domain of longman@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=longman@redhat.com X-Rspam-User: nil X-HE-Tag: 1643733687-112823 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 2/1/22 05:49, Michal Hocko wrote: > 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. The page_owner tool records the page information at allocation time. There are some slight performance overhead, but it is the memory overhead that is the major drawback of this approach as we need one page_owner structure for each physical page. Page scanning is only done when users read the page_owner debugfs file. Yes, I agree that scanning all the pages is not the most efficient way to get these dead memcg information, but it is what the page_owner tool does. I would argue that this is the most efficient coding-wise to get this information. >> 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. 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. Cheers, Longman