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 DA530D68B37 for ; Thu, 14 Nov 2024 16:36:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B5016B00AB; Thu, 14 Nov 2024 11:36:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6654A6B00AC; Thu, 14 Nov 2024 11:36:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52C756B00AD; Thu, 14 Nov 2024 11:36:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 33B326B00AB for ; Thu, 14 Nov 2024 11:36:41 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7DC5BC127E for ; Thu, 14 Nov 2024 16:36:40 +0000 (UTC) X-FDA: 82785251892.07.277D05A Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) by imf28.hostedemail.com (Postfix) with ESMTP id 5C021C0011 for ; Thu, 14 Nov 2024 16:35:53 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cxCzKR6q; spf=pass (imf28.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.173 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=1731601962; 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=Vup4/bVsV8OYHJC5w1hijbOlf10IE8njUoT5stNuyaQ=; b=UWjT+GkvEmzgLtkQhxDa/wT1K8sSP89cHRVaixRMiMwGvYEUHyxvTPq8ZlPbQz9dHHUqHp 7Gu1lVisF6LRY4vrssegVkcdDXSo17waPSZQmrO0N7jO+qcXe7159xl6lNH9H5VZcg8GMV ev1d/MYfiU/LUw5bRxna5XKw1wkQiiM= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cxCzKR6q; spf=pass (imf28.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.173 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=1731601962; a=rsa-sha256; cv=none; b=xB26ISdQD50EA9fK5Y+ttA7Xkg2XuXU4qv6XHpUnpf0s2Uu+urGog4iDBkfYSXq2Rl4QWK JPEPZ0C5AqtqjE21sWBFevGHtoXl8xTNYybru+/btyEkUVGwqCrNdqHIVIIiyKnfDBl8V0 CX/GtRU+oQLF3dBPwCbakXolRiI2hps= Date: Thu, 14 Nov 2024 16:36:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1731602196; 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=Vup4/bVsV8OYHJC5w1hijbOlf10IE8njUoT5stNuyaQ=; b=cxCzKR6qu2fmZZHZi0xd9UwRhtEz6Uh5DSVlrqUq5NE5ncuW6eARUNpYNthIMAUxWN2Tf2 sKGasxz49LX254Zx0AJyCarnxPJi1ipeXLr6HwD8ftCxsf/iYBsT9z1dlxnA5yZ8u6cfeP OobwuVlz+TdlSzfU8iUaG3PYbltV7yk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Johannes Weiner Cc: David Rientjes , Joshua Hahn , akpm@linux-foundation.org, nphamcs@gmail.com, shakeel.butt@linux.dev, muchun.song@linux.dev, chris@chrisdown.name, tj@kernel.org, lizefan.x@bytedance.com, mkoutny@suse.com, corbet@lwn.net, lnyng@meta.com, 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 v4 1/1] memcg/hugetlb: Add hugeTLB counters to memcg Message-ID: References: <20241101204402.1885383-1-joshua.hahnjy@gmail.com> <72688d81-24db-70ba-e260-bd5c74066d27@google.com> <20241114052624.GD1564047@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241114052624.GD1564047@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5C021C0011 X-Stat-Signature: 6qd5gcqwkjrqdcrcqewq7khgi58rdmxu X-Rspam-User: X-HE-Tag: 1731602153-146844 X-HE-Meta: U2FsdGVkX19lmuL/wRsig0nxA8PbW8X8rL6306awHlFh6QAf3JSVlT5OVCv7eMRa4MdpLA+jiI4giJfY3Q5ILNmc3HSxBhGJYQkpuWkVGqCi+MiSxOdv1ldPB69CKOmc+sIVa/BSkCDMvj7bz5mDeBC4EjJFZ2fxh7zGtwj5AixVlLsUUSJHR6G2f5feuUNmD9HecrCD/4o+/cNfHT0F6SGtpV03pgsG9XOAFeE580d3bWGWM8WzmwDus3rkQLfYTZRLOk/zjlX1WDKdoz1dsvTSh3673MUSK1PQ2g/rmaDqlAWHbsU96SuSU0NfBhLDgnQoSXlVuelO2N+d4RnjXmEOqVWfQRVaHg4wHABPXhE0+XNjBhzVObtrQYsrEiXGGd7lNhxOUNCdZtGVqergnAg1cdKjvAEc1B5LMzrVq59yPbc6rq4k+s1rOI0p4/VOVONYUsyFYxXoAr/hjXLMdA4ZCsmf3vB7fefAWTIu1QIQyOtItDBo6H16WKv3G3C8KWHI5S7M90PFV9glg30ztqN04MInqtKNjrMLxCSkKXuKRjco4/ACpLUCxdvyd+hjdsU/clneKnzBFC2A8GERYn/ZiYW0Z/KxorIR8wwD+PKUX6TiMxo/YmXrmKQzhaUwmnkIsKrY7lF2rpD0WZp8iDMvedsHGOucXRwIaZZfOykaqGEkic9QQfMy4Us7G8Krt5YMJrOeRDfUCNcw1OwNIb3BGNlYxvp0juDc+8FQYQtnvxnagGGhADs3hI78QtiuYNaJ+LnXAZMwOirxQuYHHK81VW+Itqk7IBx3mpBEgTxGjs9ZKMsBICWDoIinjakqk+smFNRvLIBT07/ggGTZ4xD4b3z9pApLMuwEhIB/fGcPA0RJvEb6hhGmib6QocrUrDC6xbQYnCfH6nOO/1O/Vl9lJXBdKl6UOSGLcqlpOsgFQX0rpZ8K7JPXuFg0gPlG1c/KD4XK+Lw0/Y7orTk QWYJu7Lb ZPne6YwEtiuOlk/iSmmnD64xG+6a3W9+6ZEvp9toKmLiMtGEW+3O1PDwnxMmy9uaBR4af8KNqArjvwws89CbrPdHCOMhjVSGAcrmGwyJH0ud430a+FhCk42AEWbKnhYfGZ9P5pj78KD8wv4c0CJzF3Fy05wuK8N8mX5225kABlFfQocox1rv6iAdqC1Bd0J94h1G4B6lmz2k26PKAjNmJ3xzCeF13YF50UvfTzhJt1Z0i2Oxubt2nF4AT6JtTHWaYDksU 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 Thu, Nov 14, 2024 at 12:26:24AM -0500, Johannes Weiner wrote: > On Wed, Nov 13, 2024 at 02:42:29PM -0800, David Rientjes wrote: > > On Mon, 11 Nov 2024, David Rientjes wrote: > > > > > > The reason that I opted not to include a breakdown of each hugetlb > > > > size in memory.stat is only because I wanted to keep the addition that > > > > this patch makes as minimal as possible, while still addressing > > > > the goal of bridging the gap between memory.stat and memory.current. > > > > Users who are curious about this breakdown can see how much memory > > > > is used by each hugetlb size by enabling the hugetlb controller as well. > > > > > > > > > > While the patch may be minimal, this is solidifying a kernel API that > > > users will start to count on. Users who may be interested in their > > > hugetlb usage may not have control over the configuration of their kernel? > > > > > > Does it make sense to provide a breakdown in memory.stat so that users can > > > differentiate between mapping one 1GB hugetlb page and 512 2MB hugetlb > > > pages, which are different global resources? > > > > > > > It's true that this is the case as well for total hugeltb usage, but > > > > I felt that not including hugetlb memory usage in memory.stat when it > > > > is accounted by memory.current would cause confusion for the users > > > > not being able to see that memory.current = sum of memory.stat. On the > > > > other hand, seeing the breakdown of how much each hugetlb size felt more > > > > like an optimization, and not a solution that bridges a confusion. > > > > > > > > > > If broken down into hugetlb_2048kB and hugetlb_1048576kB on x86, for > > > example, users could still do sum of memory.stat, no?> > > > > > > > Friendly ping on this, would there be any objections to splitting the > > memory.stat metrics out to be per hugepage size? > > I don't think it has to be either/or. We can add the total here, and a > per-size breakdown in a separate patch (with its own changelog)? > > That said, a per-size breakdown might make more sense in the hugetlb > cgroup controller. You're mentioning separate global resources, which > suggests this is about more explicitly controlled hugetlb use. +1 > From a memcg POV, all hugetlb is the same. It's just (non-swappable) > memory consumed by the cgroup. And here too. Thanks!