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 5A7E8D5B846 for ; Mon, 28 Oct 2024 22:38:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6B7B6B00B7; Mon, 28 Oct 2024 18:38:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF4CE8D0003; Mon, 28 Oct 2024 18:38:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1FC06B00B9; Mon, 28 Oct 2024 18:38:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8F22B6B00B7 for ; Mon, 28 Oct 2024 18:38:29 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 07367406FA for ; Mon, 28 Oct 2024 22:38:28 +0000 (UTC) X-FDA: 82724475162.13.0DDC41A Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) by imf05.hostedemail.com (Postfix) with ESMTP id 605DB100002 for ; Mon, 28 Oct 2024 22:37:40 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gfPXs3DI; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=shakeel.butt@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=1730154948; 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=bwLK6C+LIHsSNngRkDjly76woCmDfdoJJBIoyZxpefk=; b=FE4OGjjJBPIjX8O5vNTNi4FvMbQFlqIP+rhKmgf+guBmyh6QEDnkkDFiZLvtYDZk+c9O7Y UHdTRI8EHPB61hflpwS0xkMYlY4kQ3nVept5uytfif4KkAf6ZgzJIaOtVbjPdlsbJgsLCk rIya1DcANpB+0W0clniCvGfTB8NwPJQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730154948; a=rsa-sha256; cv=none; b=yQvKXEKI7b3KAiF+iekSZRwAqcBUyaJDKduX6EU7D1F9obpnGjJstq5svL23yqqWO7Iqr9 IxyuKOF7WHO4on4ttR2dzaZD+o1d7eiFQso9E+Yhzd7ypGNWdv+C0bqcZXtwranAlcExZP 9LEunbgO8p67AGBxW6rUjKI4pSHjz0w= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gfPXs3DI; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Mon, 28 Oct 2024 15:38:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1730155103; 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=bwLK6C+LIHsSNngRkDjly76woCmDfdoJJBIoyZxpefk=; b=gfPXs3DIE87maV//JfRwM0t7efKE41bpOiF3xgjdXE/I3w+No0ES7jpsFkVQ8JF2bZfBYd tBk1G4DPwru2/rXmlMfertXT43xysWl6HChbe9n70TskUmM5pvWSJYBZkE5EVbeALnGS6X oXyc/tfy1W8TdE63D367dqpHaIltCCE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Joshua Hahn Cc: hannes@cmpxchg.org, nphamcs@gmail.com, mhocko@kernel.org, roman.gushchin@linux.dev, 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 605DB100002 X-Stat-Signature: xewr1tq3efubttkhnecwg8p9437h7ba3 X-HE-Tag: 1730155060-399033 X-HE-Meta: U2FsdGVkX19+Ia37+EYNoCQm6Q4ZwDacVhq+cRjLRujRjx1sPz9V+W7hJ/p0axgdRHPL8hYm4U8hSs8ENeZrmzcd2NQnaB0E4Vk25VJ8Xjg65N25NiXZdIj/5mEjIp6grYF/WBFjV60nnxZr+PeIpidaQL+xo4FZuHGebIjUCWLhFd8U0wlMJJotctv7QEYbj2TVNZErcSt8YY3i0w4G6NbGeaWiXnC3OXOikFjgzAFWoCy/Xh6mgCCIH8sLwY9vCirkNNc/sxJPYdirb6NEiV9rhoxVcx6ESGz1tFa10zir/DmDsUvUoiYbJGLiW5qbDASa9YyXnajM+dXJ7Zwi1xygChqN2k41R1zOTnnMWUTLL17gbuh7LInlTsw2oostI9NMuceu8IPi8oPTsb0D34/PHJuct+g0+He3Xs4N1ISlzLsWe58dzCYT+KcdzBnD7+fVjEC9nfwHBPodbqTULvOkPPoYvX0kij9+mWdhir5kL4so1C9ZoTHFvtwXGCWT7QlSGMFU3LYza+LscsY+vqugMct6X+c5+3UJ1vOL7G/IrdJPSaaFOyZSnNa9vI8n2aBcZD+hkjHzou+aJohpINKC0PZvgOo86WlVrzF7y2CWU4eZcmMEd80pXDoIB0lBhE9kFwWOFwjCt87WQh3t1Y+g2LvBAshk7Ujf8AjwqmOjVyJHEKyAngUQMLVRFJq7GyUWLu/2GP1UUrdW71Ep8PVwKNBjuYFav7YtX743COJh4/sqgjsZN9bdSyncCI29c/uZJbCJdVc0hKoeQN7qN1KZxJDj+IQfySNz/T+ZfmhM3PabtiYI65tqmFg99hGs865GKbs2ztloHfu7D/XgJZvxnKAFEXoiTKf/w8DJ/xZrO9Z4gHOQ0wXCz1xs/eRbhkyuSPIOfyvoeKLi/APJ9XMZjfWM1BeHu9xVzPgAThSVSN7bRkVXKcphruNxvxjAa6UCKbDxVnf9oo+Krji g6cnGjpa nT3AhG5URwkVY65t80RMI8z4N9z14Qwkpm+GAkdXh2Dagk0dg27oWnmS8l4sHnf3pbVV1MfovWGtrf4ZWgLVf0c1aiog0GWfvANsU1CFf7eMRG7Se5pjHcDDMluYd6vHpO1Gfg4LMEuKmO4hSjj9msTIhiFmVG4xWz/TP9sIGW+UCHptrCveMsPJR+8ZMLgk9ieEBroeuRdwk+g2Luk3zCrGL4M0zoEzIJFCUPB6T023X1Ng3QpPkd1rbqwWFK8KePbG1r7U2LNkw7Ic= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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 GMT, 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 Acked-by: Shakeel Butt