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 8EDC9D3A696 for ; Tue, 29 Oct 2024 20:28:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0EB4E6B0089; Tue, 29 Oct 2024 16:28:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 09A4F6B008A; Tue, 29 Oct 2024 16:28:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECACD6B0092; Tue, 29 Oct 2024 16:28:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D41EE6B0089 for ; Tue, 29 Oct 2024 16:28:29 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8309BA05AF for ; Tue, 29 Oct 2024 20:28:29 +0000 (UTC) X-FDA: 82727777244.02.941489C Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) by imf02.hostedemail.com (Postfix) with ESMTP id 58F6B80014 for ; Tue, 29 Oct 2024 20:27:40 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JIFVDjz8; spf=pass (imf02.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730233653; 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=/krkHZhH3d22lI+5CXQ8I3yC4kmpYVhP1+xBMxmHYuk=; b=UxxUrKIxupcwofdm0KShkXpACXhwhf546uu6KFCx9QLRN+rDkyaAuoHNZ+B/N2a+QB/V73 TSr/odZXOuT0ydbbd8s322KepKacNj77PQmWWDMWi08F4FonNPwtrsgqKT0KoZaIWEadGO 1fPQGF1Z8rcKQZmnCjwOOaKB1yz998A= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JIFVDjz8; spf=pass (imf02.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730233653; a=rsa-sha256; cv=none; b=Rq92GGUASjJ7zr2l6cUjEx1Em5OxYsRB4uWwozvQH0Za90uU6SIoVaHI4DDbQQq21TBUJA oNWKQY0QT7uI+WiVAulDb0nSzjzsEYUVk7YR7dI5gqVxPGGDsDHy4KcGKC7X98Qav8Ypbo aGFTo/Low+8jhU4dTLj8DY1Xgu26Km8= Date: Tue, 29 Oct 2024 20:28:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1730233705; 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: in-reply-to:in-reply-to:references:references; bh=/krkHZhH3d22lI+5CXQ8I3yC4kmpYVhP1+xBMxmHYuk=; b=JIFVDjz8fe+/gYuEyC6SnDLSfvTYtWRcZ8/QdEI+SKyapV8MX/WCvOHeIU5r48y33O3LVn ppihBVH/TRprJdoXef8GvlTxLTGcANUNYgD19WtM+ivqQTZrTGCCeQ5EqAzqa8S2dc0cpg +sCH6R+kqvI9b1BUehaGRFzwUuSuyzU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Joshua Hahn Cc: hannes@cmpxchg.org, nphamcs@gmail.com, shakeel.butt@linux.dev, mhocko@kernel.org, muchun.song@linux.dev, tj@kernel.org, lizefan.x@bytedance.com, mkoutny@suse.com, corbet@lwn.net, lnyng@meta.com, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v3 1/1] memcg/hugetlb: Adding hugeTLB counters to memcg Message-ID: References: <20241028210505.1950884-1-joshua.hahnjy@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241028210505.1950884-1-joshua.hahnjy@gmail.com> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: q3hxmdra9iekob1p8f3n6j9zr9sobj3n X-Rspamd-Queue-Id: 58F6B80014 X-Rspamd-Server: rspam11 X-HE-Tag: 1730233660-379395 X-HE-Meta: U2FsdGVkX1+wAQiq8IwcEI9bs9ETjy5SoHE+ugVK92TNjO2RUGeCpDrn2tWdgyzl1jgQWhpQ62TyKmaUyvbXHfIxos1XDL9YzyfJ1/kCw4amF+FPx3i2VWIEycgqG2BdIx4TYDVRTVHl/wkyoe8kLzq1dcGjZSF8xn0YKjeKzc3UdwLA4sstqIlUg4C9HaJ6eK7DZOqxbSiHFf+OZ2+W/eccRndonOvzQsxcZE1sImCK3E6ETfjcBLG43OV6UgjO91T1yQTcXYcKTvtzpjBHpuVAf8ohpA+8hI1Nc0WMBrNkB/7OpKT6BOZFacpjUQJcNZ5ENNN7X6xDRTD6us1n+nwO8lnrw3a6XWxOi9LKjLt9gKqohbInsQIYnFkpnPiawbDkcR40I3RcRPwnePVNLfgZK7JSC6H4tvviJ8P2GEiNrbE3bjWIuXkrNABo3ZoMQcJEWZmHWEFr1DRwbnrHNKP5RAgel+qT/mpeeJYG0O19iURCOtXKogY9zYsxI3mwFuR4n9S1G0SsAvfJrubK3vMTqcGe6nJm4BzCJMp/TUHdotUkgL1lMhCDJa1hFC9TcUIxfIrRWzRqlvYUGprI6dFkQPHeHdwXMKDE0LPB0U893Jv8lsV9sPs1dcah60STPFcLnEX9yGmakTvQf4pWMjskmoZVDsBO6puDid8aEFVIIHt3SN5ec5ciVJA2LpgAEa86gj5bTOHuNQBQEeNMWboHwBrRm5PIQojT1+k/CncMkQbBlRzmjW+36SRPSuyLMTXSxSw/8qjrBpTg0Jmz2lsiTQA/HMhLLthfOo8RylMZP7xxMFvNU1WdtZz6ikcHSFQQZESlcCRy1GnAf6VrEBN66N46p2OYCxxeXs3d5rybhoMHF68rDJOs62B95gQh8NATWV+lBoZvCA9pgf35AZCuCjPq4xbWsLYr2MB/9n4pC7bWzXs/mGfUfbQHtRPq7guGIXu81jM9CMaKdlw /AaDTSMB FFPHYZAaSnGPbj+JefqYDpePRBjYyI2iEfzREkNbyrxLZxnKMXobm6kIJlwlJeyONq8UEH/gFKcuODqYWI+fj4Jcl6bJ5IeB9SYSx4XRDn5/3ta5ND7cNK2ZfYHuM0T/WGgxuuyYTi1jTU6zWV70sQZlTdEtxg1zrzcY+35q/PJdSasu5FMyqNn2XWvtw030h667CZ4kiwJ8yKjqk8sL7Xr/TqsOKATeShCNHqpefljy+FhN3ZG6vv30ZhpNAFS1X+mgawByxkvm/4B8I3asJIpg8xHHaGxgqt1Ld8vvnPdCBqFM= 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: List-Subscribe: List-Unsubscribe: On Mon, Oct 28, 2024 at 02:05:05PM -0700, Joshua Hahn wrote: > This patch introduces a new counter to memory.stat that tracks hugeTLB > usage, only if hugeTLB accounting is done to memory.current. This > feature is enabled the same way hugeTLB accounting is enabled, via > the memory_hugetlb_accounting mount flag for cgroupsv2. > > 1. Why is this patch necessary? > Currently, memcg hugeTLB accounting is an opt-in feature [1] that adds > hugeTLB usage to memory.current. However, the metric is not reported in > memory.stat. Given that users often interpret memory.stat as a breakdown > of the value reported in memory.current, the disparity between the two > reports can be confusing. This patch solves this problem by including > the metric in memory.stat as well, but only if it is also reported in > memory.current (it would also be confusing if the value was reported in > memory.stat, but not in memory.current) > > Aside from the consistency between the two files, we also see benefits > in observability. Userspace might be interested in the hugeTLB footprint > of cgroups for many reasons. For instance, system admins might want to > verify that hugeTLB usage is distributed as expected across tasks: i.e. > memory-intensive tasks are using more hugeTLB pages than tasks that > don't consume a lot of memory, or are seen to fault frequently. Note that > this is separate from wanting to inspect the distribution for limiting > purposes (in which case, hugeTLB controller makes more sense). > > 2. We already have a hugeTLB controller. Why not use that? > It is true that hugeTLB tracks the exact value that we want. In fact, by > enabling the hugeTLB controller, we get all of the observability > benefits that I mentioned above, and users can check the total hugeTLB > usage, verify if it is distributed as expected, etc. > > With this said, there are 2 problems: > (a) They are still not reported in memory.stat, which means the > disparity between the memcg reports are still there. > (b) We cannot reasonably expect users to enable the hugeTLB controller > just for the sake of hugeTLB usage reporting, especially since > they don't have any use for hugeTLB usage enforcing [2]. > > [1] https://lore.kernel.org/all/20231006184629.155543-1-nphamcs@gmail.com/ > [2] Of course, we can't make a new patch for every feature that can be > duplicated. However, since the existing solution of enabling the > hugeTLB controller is an imperfect solution that still leaves a > discrepancy between memory.stat and memory.curent, I think that it > is reasonable to isolate the feature in this case. > > Suggested-by: Nhat Pham > Suggested-by: Shakeel Butt > Signed-off-by: Joshua Hahn Reviewed-by: Roman Gushchin Thanks!