Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp4488386pxb; Sat, 5 Feb 2022 15:46:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJwtqQWo73eUVFqJAjiFMUqujZ1+N8yoYNm/amRAeMvttqdskdXNPrOqojnjXk+PvKo2azEn X-Received: by 2002:a17:90a:f414:: with SMTP id ch20mr448406pjb.146.1644104798845; Sat, 05 Feb 2022 15:46:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644104798; cv=none; d=google.com; s=arc-20160816; b=BUu0qbECeS0BDhJU3UnWbqQZ0HNvYhNisvvozQ1Mr92bIcdFva0yZXSSnKkSZ0eEpl ky3gihqZvgdXxKzNNF7LYp9/m0PXU62an32uXEQxpoW0jtrpM86CTDYkvZidYWnB09MS sP9GiBc5hRNrBM41nM3lyHfeVKwJjQI9KmABGjqsX2SxPNWValJckwHUKIEocfBu8ZGr ondYdD0Su2/py2m3HLn6D3tBYsM/oJHszpoRee89DzOSgkR8alSKXEx89ocvD5Hjb+uG nrG8RJQN5f9wrCa+Hl+vWy6FiTykFBdxRQTYe7MPkwAdnoDS+FE4rIcs0pDbzD4f00Cr xZmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=5odN6rMwltUoUEaPnfnI/Lwo2lMwPdE9aw/xm4uKQro=; b=n7U4/ISnYD0KWCUffxIe8r7ptsVg2KV2D/BYLuSRsQdZefeG8DKcf9flEIzdhYxd1E gVWJ+0CBo+IvKgzmLuKXk1kiKdT4p6IZKiKIFloD5Awg1jsDoO0gvRZ2VdUxbmCiqM7A 6FtuHWdxnYPXQZie10Krphclw1ZMjxXQlUaYN/ozNITfFSm+Pu1j2i5qp5poeIcvYdZA EVFAdkxSicR8mrtu8Tc38BTSRkDODEh3UgO25iG8sc7xe56Ioc8zoLdMWKtr+1D5+bYq hvnEOmMW/ryx2Po54NwQ4sIfjaxoadTj64QTPOOoR9UokCa7XTLwMkOdc/9YfK6Jabo2 wYPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=OQW1BNsJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k12si5227644pls.575.2022.02.05.15.46.14; Sat, 05 Feb 2022 15:46:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=OQW1BNsJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232988AbiBDTWr (ORCPT + 99 others); Fri, 4 Feb 2022 14:22:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230453AbiBDTWo (ORCPT ); Fri, 4 Feb 2022 14:22:44 -0500 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 637E5C061714 for ; Fri, 4 Feb 2022 11:22:43 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id b22so5546451qkk.12 for ; Fri, 04 Feb 2022 11:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5odN6rMwltUoUEaPnfnI/Lwo2lMwPdE9aw/xm4uKQro=; b=OQW1BNsJP3CX3IWKdckwO+Who2ZvMboyjVmT0ml0RenWk1xvYjkf0bhQMxcAfMVxES 63cTYk1FlcVVeS30hxkAx0J+cAToUYOHJ6y2wroPP95irRjAbEHmOswbJBkVfTVpWNHp BPaTVoWNys9F115cJfEM2Z14ChvlNhcMDf1QIbkj7HBhsdqJhO7pfEezBSZZvJ57y4fd 3TGNQGk9sI1j2hFZJF9m15H0GdtXkblQNdQ+k60O40pGbEW9ve4LXfTGO56qDhqrqFYs XGZJevT/nrvIjrjs0lOgAVexKzjJdvNDR3T2rg53j3Y+N4qYWdlShRmPWqjQchm6Oddh Flqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5odN6rMwltUoUEaPnfnI/Lwo2lMwPdE9aw/xm4uKQro=; b=o00JZ4TlTqRcWVJYqMLd4Meze831roFzfc1Km9Apb3w9O3JzX5X+evq2mIwNlyiW9F go683bIAWGFXHmLSvpXFpiGeQRaFsOkx+wuI0kOUHDXjKTTxWWQ4vJRf64Unfvo4DV5H hxiyvwRmFBuS5IS7H847dp3ZX0FIqEb21sezAPBDWAHcbcnDyGpx65R3yjQXPWjlqjJu Zz3njSmORWiRYYaVXC05aM08qmLS7Ob6VDaluzofP9XhUf2021yfQNxh+IJAxRRzzEz4 QLOXliQI3f6gyEvwlM/wt7LWhvEHIPeumsA7eRsd6yI2uOGZbPKDUfchSm8iqPzler8K P0Cg== X-Gm-Message-State: AOAM530R/DW7Zg9/iZqjpM+MKzgksD/l2T4plUI4yt2B1T3DOsv9TfAK z8niVr8igbSGyKkAcq2p+y39qA== X-Received: by 2002:a05:620a:4093:: with SMTP id f19mr378593qko.306.1644002562420; Fri, 04 Feb 2022 11:22:42 -0800 (PST) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id u17sm1551317qkp.90.2022.02.04.11.22.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Feb 2022 11:22:41 -0800 (PST) Date: Fri, 4 Feb 2022 14:22:40 -0500 From: Johannes Weiner To: Yosry Ahmed Cc: Andrew Morton , Michal Hocko , Muchun Song , Shakeel Butt , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel test robot Subject: Re: [PATCH v2] memcg: add per-memcg total kernel memory stat Message-ID: References: <20220203193856.972500-1-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220203193856.972500-1-yosryahmed@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 03, 2022 at 07:38:56PM +0000, Yosry Ahmed wrote: > Currently memcg stats show several types of kernel memory: > kernel stack, page tables, sock, vmalloc, and slab. > However, there are other allocations with __GFP_ACCOUNT > (or supersets such as GFP_KERNEL_ACCOUNT) that are not accounted > in any of those stats, a few examples are: > - various kvm allocations (e.g. allocated pages to create vcpus) > - io_uring > - tmp_page in pipes during pipe_write() > - bpf ringbuffers > - unix sockets > > Keeping track of the total kernel memory is essential for the ease of > migration from cgroup v1 to v2 as there are large discrepancies between > v1's kmem.usage_in_bytes and the sum of the available kernel memory stats > in v2. Adding separate memcg stats for all __GFP_ACCOUNT kernel > allocations is an impractical maintenance burden as there a lot of those > all over the kernel code, with more use cases likely to show up in the > future. > > Therefore, add a "kernel" memcg stat that is analogous to kmem > page counter, with added benefits such as using rstat infrastructure > which aggregates stats more efficiently. Additionally, this provides a > lighter alternative in case the legacy kmem is deprecated in the future > > Signed-off-by: Yosry Ahmed > Acked-by: Shakeel Butt > Acked-by: Johannes Weiner > Reported-by: kernel test robot Looks good, thanks Yosry!