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 86B4CD74940 for ; Tue, 29 Oct 2024 21:04:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 063FF6B0083; Tue, 29 Oct 2024 17:04:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 011096B0089; Tue, 29 Oct 2024 17:04:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCDE36B008A; Tue, 29 Oct 2024 17:04:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BC9D26B0083 for ; Tue, 29 Oct 2024 17:04:41 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 732D9C064E for ; Tue, 29 Oct 2024 21:04:41 +0000 (UTC) X-FDA: 82727868048.12.5F83D4D Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf21.hostedemail.com (Postfix) with ESMTP id 289971C000F for ; Tue, 29 Oct 2024 21:03:51 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JJ54wlz5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730235750; a=rsa-sha256; cv=none; b=4WskQInEpi/GCT5Amav3YhU9h5Evqza5qDkuUY37isFAaRMmBUlDCuV2So8BEwF2KpwxCu HEezrUAIBBkP/KUAP7gHApwrTIPwvUEEwPqy91H+SNdd3of482cpZ4Al7dohxrp8+bFIi0 Ab4W0VBD1krArPHnzeJB8CkQwqNyHSY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JJ54wlz5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730235750; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DWF4JMlMslw/GFDtipOIiN9c4I6myuF71ODQ5wMy07o=; b=Xb/KRqG19ut2TTqh0Vw8ZYYHGEuqu3+RnOkhtDtmLrEZIg2m06udb+XsCvMwjmMXC8oXLq +ab0yY/nI7qFI6e3CEO+BbCu1PAikv3IZZqOWCkY1UKVfLrT42LzqLi6Ok9uMcy3nttwZ2 HFTmCkyy45p+hxse2lyu72sOIME7zQ0= Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6cbf0e6414aso29222466d6.1 for ; Tue, 29 Oct 2024 14:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730235879; x=1730840679; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DWF4JMlMslw/GFDtipOIiN9c4I6myuF71ODQ5wMy07o=; b=JJ54wlz58Lv8h77TqhBiyo5TQXC1W3A2HnE7OGFR2hYJs8X8ociUFWK9F/bUmBQN5a kX4/HwvcOIMjWW9KYe3zvVxrO8lpDGsC/MfDWmKBPQP7tUGYvnnGEcyE70zEPkZbq1AS CclOnYbqOWuLOvwNH0S+jrBlM7/myjNhbcrF/mNVo+DIF1chFYzKA9PxMlcSeLFtBCPJ ty1DO421dsZAx3dujO9qveg/R468MdpB6ZS8u57ZAGloXf/g/Ow1aB6+zpbsP/XzT6mc dfXTCEHKcSW3Wx5kHSqXASHTywZ+fr2svcYR4/doQGo6cdbIdHxBg5H1FsWY3fnMSrV0 YChQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730235879; x=1730840679; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DWF4JMlMslw/GFDtipOIiN9c4I6myuF71ODQ5wMy07o=; b=VjNZOdmOFR6m3jr3sKxc0mlJjs168+uJA+7jdmx30gmrljIX3njQaBwiLhNSD+Fzut AsXVLwVDf2V/2cxxBdF5yqu5jyJrZrgsxQeRW3lXxdqMwLJV9bSAYtZ/ySuoX05WZUMs e1fkRh8POd1BQTb8ejHpc3wzWkrUepeQ0T/AjOYpg+EB3tmq0o+5FPmWNDZsVByonUoK qOUCKIlUiF+A0yF3uKqWHQ2J/ipzbren6yvmLItJ34pepsIbSG9aksu9qCL4VA0nVYyS rB8OTnpCaG4UxXHYvekTovqgelYpAfpans8JtlYUed0svliFrLHFD4MUlBpLePuggFMe xRNA== X-Forwarded-Encrypted: i=1; AJvYcCWa8g4nauNyW9HXg+JPLJGdpYFeyCPrHlE+VYNhTJoaPYBETRzaCr0QwpEVLeP3fZLoBRYTSyqjYg==@kvack.org X-Gm-Message-State: AOJu0YwJDomPTNgi9H+A9zrdpjaAUzIKAeXL+M6cjVcruyTqdrLzijfg mFD4DxmolUA186mBUJp7CfuE5/V5gI7+xOy9/sunptIxjQ/YACFIc0y7FNbol140PM51RXqaolq ppD42Eybidz4cyGrf0XKhHYpLEsI= X-Google-Smtp-Source: AGHT+IGYEoKUfjapXifSa0HhvXycaqStroq848S5VfperkjE7/QZ6rz9oqVgiXSzkVHcWlH65oViCPKZR8cx3Soq7gk= X-Received: by 2002:a05:6214:3d11:b0:6cb:f6de:3d11 with SMTP id 6a1803df08f44-6d18584fcfbmr213619256d6.41.1730235878766; Tue, 29 Oct 2024 14:04:38 -0700 (PDT) MIME-Version: 1.0 References: <20241028210505.1950884-1-joshua.hahnjy@gmail.com> In-Reply-To: <20241028210505.1950884-1-joshua.hahnjy@gmail.com> From: Nhat Pham Date: Tue, 29 Oct 2024 14:04:27 -0700 Message-ID: Subject: Re: [PATCH v3 1/1] memcg/hugetlb: Adding hugeTLB counters to memcg To: Joshua Hahn Cc: hannes@cmpxchg.org, shakeel.butt@linux.dev, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 289971C000F X-Stat-Signature: 6w8t78yqwbr7zqgngwxo8mcwze43ypod X-Rspam-User: X-HE-Tag: 1730235831-727118 X-HE-Meta: U2FsdGVkX18NepX2S18oWWQbrp13ERByPecgBZQHvSzmfkarUCUZHl7oUdJ8rCzsYbOVAeGm+LPVw1hh/qOsJ9eictxFR5k1R8u68ocU96mSE9r/tbf4fzLUC1h8Yh2uqhLPWO9dvjU59M/eazMRgfyCyuh9AWZuJU9uvMGtKj0ycd6xqGEoSPeE4eAobf+vjjFINq2FRqDgyGzHprr1OybAhhU8OwfmR4JzPostqLnlceIxywuawFu4eD4+BRKxya2EFCwzdzLSqVwwZT9l+DpeiFC1YK+FuxPGr54RWOkQgQVfwEKzKeH8EYoE8mM8aZLkGW9bzVySpcm+sXiNsWITqEH0DiocLiyxNChc9Tv49QIrtC5E/ddv56SEbAbN2sLU2SH5/ieHUECfqOeHXSZVeimy9WmD+5GUOsHPsjZUVC5EhzYAEF2ifdCNiXa8CycvrzbcivIBDI8lchqfpZAJO50xtw9e40xg1KUcBZ5isU2wNJvvSafxQ2u1AvGi06L/Bw3hYTI89P9oGMwYFrBRSfcp/U3CCmHtu6OZ1X6YHtDAuNHzBXlk1uMsCcCftg/yOKjXnUtkCQo1bgMBbWpUh89UWoVbauTpKjAr7y3lw6EK9SpSzIlmw4ollOWOxBF3PNseCUoxaHMnHuSXtXoh1B3y1SHVp/rDnmd3vqGtElvfTpiDBFZYUlLNfFb7xmevXNYieegpJGSmUy3YpbI0Zvx50ScxHl6WBOWLsajmzzzEdTjISitJOJTU6pcU8UkikndAy7dcDz+lgoQwtUdoPBlXbzNL4+0Ams01ehWP8qJJ07yk4GAZ/KvtQ/y9J3NSwGMHyNh7HQDO95XrK9jwuF2RrbVxxj0iXoxS6/pOcuKy4RtYLd6qd5YzGlJ0PC2Vmuku5+hzohRPwtJR8ZJ0H/IrVZFpvqYtRQdRVw8DPanWVDT1JdhbWhFMyGCEk/ovX660EPVQvqT3203 oBrLwihu 4qmGQ2TCmKl3LYtzr6+CeI5og41FrhGuhATAyAwZMeXGnhAbI4xcF2SMHkhZbJsF9zgwULUaDB+gKamiuWBKJ28uVsgHhcLzZyqRBEzhIEmiN38g6teHEDbWcXXxH7KKn33vXY+tnpw9JMo37w7kT7i9Hsy0SY4u1ww2O35TgdOzrfz6A9cQIGUIMVxsCgyvbzidqPJb/julHVAjIDR26Ra6mGdyQWYEMK/knuZLWudPgSFw9AVt1cAVqdbjXOP6ou5YuSZaN7pkdMmcbY26ymnpQrGICbJzSW5PAM1Cmq1OXH1m9XCSKKWV8ygXOWF+4OWm2cJ0BP/CWSN02fdTF6yElApyeFrliAHRXeB/47ZRt+kIoEvhVDvDUPM2idjKk1AtphbOq3X1UdBsOw10SXSF3YpmDWFInak9IrmBRwu+iQwXxvroncjz/EWsFzohJa4aB X-Bogosity: Ham, tests=bogofilter, spamicity=0.278873, 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 2:05=E2=80=AFPM 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 I'll take it ;) > Suggested-by: Shakeel Butt > Signed-off-by: Joshua Hahn Reviewed-by: Nhat Pham