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 96DD9C61DA4 for ; Fri, 3 Feb 2023 19:18:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 262A36B0074; Fri, 3 Feb 2023 14:18:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EC306B0075; Fri, 3 Feb 2023 14:18:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B5796B0078; Fri, 3 Feb 2023 14:18:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E9E716B0074 for ; Fri, 3 Feb 2023 14:18:45 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B2DD1812A0 for ; Fri, 3 Feb 2023 19:18:45 +0000 (UTC) X-FDA: 80426942610.18.44DAE50 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf17.hostedemail.com (Postfix) with ESMTP id 045AE4000D for ; Fri, 3 Feb 2023 19:18:43 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kdvGxpkd; spf=pass (imf17.hostedemail.com: domain of 3El7dYwgKCGkZOHRLLSINVVNSL.JVTSPUbe-TTRcHJR.VYN@flex--shakeelb.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3El7dYwgKCGkZOHRLLSINVVNSL.JVTSPUbe-TTRcHJR.VYN@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675451924; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eZSuQF+nJSrdc5oiEMr2Huwq3nLEZDXbSVvbFcSGTVg=; b=OO4j9SGb9NvV1lKsJVNc9xvj9isjeP4tKSaOvVh7eBdd4NlN3YpltBPqiPltj+K7O+HvDx Coia9Wn80VWhWCYOcXzZXOxxhgIjnUb0y9BfuU4pdOgnYn+utfzC1LQEoE8G4InoyYJUeb 1VHlQNab7ymO3kVDmWF6rWebbfwnSIE= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kdvGxpkd; spf=pass (imf17.hostedemail.com: domain of 3El7dYwgKCGkZOHRLLSINVVNSL.JVTSPUbe-TTRcHJR.VYN@flex--shakeelb.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3El7dYwgKCGkZOHRLLSINVVNSL.JVTSPUbe-TTRcHJR.VYN@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675451924; a=rsa-sha256; cv=none; b=vPwooa4c2Pe4eu6zEKR0C8zUvTjdOvjDYSX8MlV76CslpylErz4MzFIZ07bzhopBoJTHlq Yu2DQgt8dl1SDULovEvQsH14VnangKoY/FVRJa56nltYRxPMaQ9kMLBhyHWudCwmsmVZvm Bvao94spFmMz7RQdQPCbk2Za13fCDx4= Received: by mail-pl1-f202.google.com with SMTP id q14-20020a170902eb8e00b00198d45368eeso2018400plg.23 for ; Fri, 03 Feb 2023 11:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=eZSuQF+nJSrdc5oiEMr2Huwq3nLEZDXbSVvbFcSGTVg=; b=kdvGxpkdksPrb8vTbUnTey3IDTfFIN/yZjMk3GpmvkGAN7QnnRU6Wm0uwX3hcaow+7 T2nGox0V65Lb0aAooaAgQxOALFaDDn7Qve5uGl0s7QISeFrOG8kcYQelo67MvBD7yLAI wc+a19ViT+94h4/58b3oOPid3z4l2Fq2+c1avj5d4t2Zj0hB405MokIZ0ZN9mKkBjudm Z/Z2WZJhC65WygoAsw1ZZUC07Rx3Inh91guxjjrPRlS60hV0i8P93hJQx8GmRA84m9T/ 8//OzllptVYu4emQ1Ulx5izXKaecOAF8be+n3ke0lVMJtBRwjUSJrg487jTUVkl/EKPk 46DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eZSuQF+nJSrdc5oiEMr2Huwq3nLEZDXbSVvbFcSGTVg=; b=mSSaJQTMDIQ0K0v1pkYQepfLcSt4cS1DScvRDK5Q4PLfwc1SeYXw2xHre7QoLw93H2 r1T012UDomAK1Wny0yhZi7UlQ3944EbGJWGggbC8nwnACSNtEJcicbOrOLHw2KIu235P vGJZOqdfpybQ3gdJE8yn10O+a5Z1BFXoBaYvNnMu5dxeQ9fiA5nZMbe3G6CM0HNxhk07 4J3CrJyD7oLAED34orxUVlT48ixzlqHXZFxF9TQuu4ZfIOA1xMu8Ok4Mb2ufjG6sPqTE ueZFBH2vVoQUvu6CT2WbE3J1sspE20XmN8AcdOFjhdVHhq0P69A2ZQ5x52yGaOmPpcoJ 56kQ== X-Gm-Message-State: AO0yUKXL63WUtKhe1r9Jo4wJpS2kgXQtFofEmjiYjfotuKy9o01STZtz wfyD+AsiG2CuIU6E3tlU2dUH1azm60w78w== X-Google-Smtp-Source: AK7set+KFitv4K386psersWMjOdQpsVBs7o/hvcomAg0VVFrQ/F95zkILRWihWHNvcethbqhu8oV9vtuVKl92w== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a17:902:7788:b0:198:e13d:a04a with SMTP id o8-20020a170902778800b00198e13da04amr628723pll.7.1675451922818; Fri, 03 Feb 2023 11:18:42 -0800 (PST) Date: Fri, 3 Feb 2023 19:18:40 +0000 In-Reply-To: Mime-Version: 1.0 References: <1675312377-4782-1-git-send-email-zhaoyang.huang@unisoc.com> Message-ID: <20230203191840.jh5akertunyk4cx7@google.com> Subject: Re: [PATCH] mm: introduce entrance for root_mem_cgroup's current From: Shakeel Butt To: Michal Hocko Cc: "zhaoyang.huang" , Andrew Morton , Johannes Weiner , Peter Zijlstra , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Zhaoyang Huang , ke.wang@unisoc.com Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 045AE4000D X-Stat-Signature: 1f1x33ji9yrhbki76pjtrohuxz6r9746 X-Rspam-User: X-HE-Tag: 1675451923-949627 X-HE-Meta: U2FsdGVkX1+joAMIq84btjHlKJX5ZReWYfJgHaUeDaec7rLcumePF9A0JpIDPho9UpjoQV6yYzub47NxI/munGhexW80ot4ibe5UbKdI5zTCRcNVvOYmC1gfdVhiwW+aVKoeWzdifo5k2qitTwkFI1IMd108RnwoLYvxU63f3qjazS9BoiSrPF/LIlsn5D2Ad3/n8OELmfN+/IBW7Tw6ywT7+gfmCgOBSOz0JvtVyb2S+f0YzC6BE2r4nNYMbk7ofC05TnGLRrEybs/p1C3G/X26mzBLRZY608HIf5fLR889vdVvwRVpZuw+efYAvJ4jFfZUGwjUkpG8cn5SlqE/f2mZd7nf+QV7sVrU4HLBE4LxVEJadGyenFzTagekQvaOGKiicG5QQOvXBGt9xyenuhQ2DPgYhdXeznqswRNmyjtOp0YKmE5tWYEiz6cqcOKv3dUzVtQE+0nFfl7LE5eC4DXQY5AzJPfxF7NX8Xjel5o6d5Dk5v23LrInvAN3ZSjey9nCmPCWyMC2XIWqKg6ZpDHfqZLKLR2hSaWzeUvgxo3ZKat97qsogQMmVrU+Sny00RakSlhMpzTCcxMb3ydVuJajVVTZ3+93G0w1UWtj0VS0LINuLwK1oz/YeytavamKYCY+XsgLwVBFkUFtn4m/igm9vgIlYdr9/1gGKBO1PD/VukA9cBh8I+G73DDJL3RP6C1NrNaiVSj5dPHw1kzE6Yfm5YWIx33vANuqVRDbPZPudO5UPlH6zQ8yfOwrVTwYVnTVjI07MrxhiV2pAhT7EtZXVdu6ost/JlGZniVveyV3StK05X04v9Y4+5Gr8NxErCCFuycRzJW6gl208i9kuJO+DRd5zMfDtgHp1RqC3VNxr4fTi5SIampsYYrYjVylxGd7i+VSxHjrkC/mj6Jl9CSeeXLAvBd3Y8SOIIE2VPDH9PLAj5S6Ai5sOhuv67snZuu8n3f/YTyhGerwI2+ N0OtPFGK HMPYjncQSW/52lqh60guFjQIoTwakDsf2Z8BjbTMARR3xvSn0i6YTBVixjojAjay7IqsEuaCOTsye0C0Eqo6esDrOSYfAJGLDs4X8/aeB221j2fsxIuC3kegMvSKRlTYBucQ7k8aBS4CrN24Ql2/9xSV2KgHJ1hrWH2qaKcNi2mYXCyr9+XMa8AExBNXCWE3rosO4wQB4Rb9FRUMpkX1siDGb3081rK2xEComYlhYZcKUczsuaHV38FN3o+YGUQNSexglrC8FCDIoO0QSs6jl7k1pp33dGmaqqOXbdmu5tux+bHfZw/4gJrOjdJ6VwAaO2UfpxPimDvnqBAjuZywWQxNxONqVth3wFTlLZgv/GJhktPePK6nLk4gc/sPVWHcXVuwxzX29e21gKfgsAFs3373eIrlMB0eU6eKZvuX96UmvBw09yKPZ5sW7Ef3LcJ5CnFLp8RZZPRxJawDwftpiwOQFCOejHG2u+yuiUGL7IlLdquakX+gmgNcO7Bd0TJ2HZMIAtJocADdpkyTe3iuK1FybCu+un1u7n84/vzDTicMjUO4RCBWcDBV14y8g06IuA7GkVBQ34K3RTsqYGF6JLUBBIgRtJMOihUqy4WN4tNOl9jn1Q/7yMNnZVX4/reUYqIkcVLLlzXXCY2a5ZLzA+H8qhDjCjRvsk8bX X-Bogosity: Ham, tests=bogofilter, spamicity=0.000205, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 03, 2023 at 09:58:56AM +0100, Michal Hocko wrote: [...] > > > > One advantage I can see is if someone is looking for usage for all top > > containers (alive or zombie) but I wanted to know if that was the real > > motivation behind the patch. > > Isn't that just a global stats that we already display via /proc files? > Things are a bit complicated for kernel memory. Let's take a simple example where there are no processes in the root memcg. In this case the user memory stats should be similar to the global stats under /proc because we always charge user memory. However the kernel memory has to be opted-in to be accounted. So, we have a lot of allocations which are in the global stats but not in the memcg stats. We can traverse the top level memcgs to get kernel stats and subtract it from the global stats which will give the sum of zombie kernel memory and unaccounted kernel memory. For debugging and history/analysis purpose, differentiating between zombie and unaccounted makes sense.