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 B9EECD68B36 for ; Thu, 14 Nov 2024 16:42:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52F698D0002; Thu, 14 Nov 2024 11:42:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DF478D0001; Thu, 14 Nov 2024 11:42:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37F938D0002; Thu, 14 Nov 2024 11:42:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 176F38D0001 for ; Thu, 14 Nov 2024 11:42:43 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id ACD9481261 for ; Thu, 14 Nov 2024 16:42:42 +0000 (UTC) X-FDA: 82785266928.09.C9ACE4C Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf26.hostedemail.com (Postfix) with ESMTP id 2138C140019 for ; Thu, 14 Nov 2024 16:42:06 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VRj6ffrV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731602497; a=rsa-sha256; cv=none; b=DG+Kxkoh60fCOkZfgDMiKw7Q4wWEj4EPBjuPeMhS3mWmVGD1qY2UE2cQdhsDRAyZiwnUHz P4ak/av4Eu9VuVMH6/OaiS9WTJ/+shP5Bet90G1jNhcSK6ioiSUS8T1bHDIaKkU+iSTCwF T5YD1nLNc4CFVhbjySldGBw0Iq0VcHk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VRj6ffrV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731602497; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ddOsfjQA/2oCKHO1HaWymRb5TSJ6GIPEt0qm/4J2cyE=; b=rADlKa3s3ecbB0cICYN9xd3YhPUQiMwdEpUFedrZslF/FqA3fmvWj4vEi8PI9eP/86Qn9j AJYFg3K9d6Uv2+FxuJbWkJOqe9fx+/7t5tMfbB9kONGD13elZFaI7fjGkrNC9OOyoR8IJj DFW7RvGw0xZKU7NmQJYoyMQFCFgQ4YQ= Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-6eb0e90b729so10614437b3.1 for ; Thu, 14 Nov 2024 08:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731602559; x=1732207359; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ddOsfjQA/2oCKHO1HaWymRb5TSJ6GIPEt0qm/4J2cyE=; b=VRj6ffrVgLo7P/HskHsapAvh8JIdzRbbg4sV4veIjWxyFqJcrpCDwOnp8EPC9W9YM6 JUl3KeF6pHn95y1QnaJIJLl36i2rZ8WXX/tzJGKa/H7uXmp/Bl1nypCrRY+Y1SQ3XvsY AoGnx2hVB6BCQ4agbwI0LlHi+YoojtB/BBESTmsLoJ1DCZj3YUx5T/ojiBLigciZ+aa+ QkbyVG48Dayn2Aji1S6bZ4XCiS4eX0NWwqNcFCelo9+IabKXlse5c+0dZhzyE5BiNPcq mtHVYY2SD8GrKmcJMNxxUDP53vVMzCnISujWeZvbL2ssqiZLIrCziwREVKJ7i0g1amq9 sjxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731602559; x=1732207359; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ddOsfjQA/2oCKHO1HaWymRb5TSJ6GIPEt0qm/4J2cyE=; b=FoZrUPpZz+EdbEZ/v0k1B9kMbDCmdCwkXoah/+bUUEQnglQDbpR9/BPbDOjyj2ouIE VhVc0E3huRzDYix2fl3pTjIIPWbRyjOf8kiKkjamLjgx2XrkSF5/4n2r5d+oEdEzQTDP IA58CtLh3y2qzi1EBZynDdbWwuIndFKrCfYDYgsLpDoT42Z2gnfrhNmezBMJmqAw35pa vNIB90UMHQBSpZjgijS3zV6z5MzJ5DJrz5klCBRyISfVLzA5VeQg7rcdDKE5eOxwDr6q jKuFxzSrf4f2Rdf7hE/fksj1giRWsgkvO5EEdmpMtlz0GM6pFxJ72PBgEfe5VzIq+m3g /lHw== X-Forwarded-Encrypted: i=1; AJvYcCX0SUR+1Bgt93sE9w73XqWM2XlWcYe9uO619PpztLOAzpLKLBLrWmFCIfAA6byz0eFy0VTH1qg5kg==@kvack.org X-Gm-Message-State: AOJu0YwwaVJaUVSKMbrW8tYQZMFJp3TPStjo0qs+lg1Mw1V+z0J5hF0+ 89XWaR9zPj1UcYGGIxMCTSGG04FM9RRVJg2yx71tyB7YZJj95+bu X-Google-Smtp-Source: AGHT+IHOjUhiYk7Hb1BJ54uGaSVNyjUBIW5p9q05WgczyNwz6DZIXTBgRjjqTPGcZw4cE5k5Yrv9Qg== X-Received: by 2002:a05:690c:4d4a:b0:6ea:5da9:34cc with SMTP id 00721157ae682-6ee4333d176mr30454287b3.7.1731602559639; Thu, 14 Nov 2024 08:42:39 -0800 (PST) Received: from localhost (fwdproxy-frc-022.fbsv.net. [2a03:2880:21ff:16::face:b00c]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6ee4444783fsm3129317b3.104.2024.11.14.08.42.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Nov 2024 08:42:39 -0800 (PST) From: Joshua Hahn To: David Rientjes Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, nphamcs@gmail.com, shakeel.butt@linux.dev, roman.gushchin@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 Date: Thu, 14 Nov 2024 08:42:15 -0800 Message-ID: <20241114164236.1790279-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.43.5 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 2138C140019 X-Rspamd-Server: rspam01 X-Stat-Signature: 1tzz85wc7n3m4z1xowue95ysu8ocnzjj X-HE-Tag: 1731602526-137589 X-HE-Meta: U2FsdGVkX1/NENygG/RTd/NOm3RKvrJUFNQBtNbUu/S03Z8qvQFhUtk6YRjLJh/E1yR9JLXn5UQt6KXSuZnzHTx/GhJUR2EXUsAuFvr0w8zRHvWJbXq1Jhk7nKnW2lfs6LvW5ZZLmGDFetykd6jDo4Msvoi315en6BxQ+pfxzzz13eX2l9TZJyUwAq2ERkRula2/DuABnIGRQAsgGjCkJWWq1HOL00CXX7AqGwRLKF2F1hskalVgBODxlISU/6SQQWcg6jH2//X37GcWbITeAXOx0nOd6wry570+gB95fX/rvFXploBm9i7g0xg3SC5NMFBHROB/9Sz7+fUcV9LP4F2K4hjVuP0XZE4xGKLs1vbiEOgw2Hqtoir1pUiZxEzY9zlUyUJ48ZhgXxnOXi8LBLGpElVoKzcy9aq9IxepJRWrSLQrm3z/iD645A3KigrXWuJ68WUXguFyiwoDc/6/n8x/BBPAY8J0DeEIt3zpfDHIK0760gUDh/HX5ITBa5RI/RBD4XMpnIbfxjoxRcWl2aKXj/Oyr/v06N/cT/m0VJ+Srv8oHTWnS20k711H5l3mxcwcysSM2lmUMEkufWMJPj93oXPHEa1waBRw2zeyYA3ydzJweNonudHD8VsQkqegwSBd1sb0jVyOMzQmQkHuqypS25yhSzc8Cglrjeh5sIv7Vray9sga2tihAhHnJ3kls0QUfaqbndgUCV7P1VMdUyqLqas1xTfelS3/cgTiXYdNoHCcxbErfJxuTQBueyT4mJKknULZT8lM+GGTUR7FhFbHRdIVxv6D8vYm0LmD4TTxOMMmW1IHVC1YgABAfGFUaPON4GoFI5F4hhMbqGecBdRiFKdMjUbA3nZWrP2Yi3cgtFaYjmaXN6H9vT1EvsjOZmuv4ZcEXF5eDCrk8VXc703QyPKvdkRamp12VdqUuxiKlsxpaeQF9XHw1qywCouFf6JeBOIPzOOr8yN3e0E SunpvhNf 0hdUGI7JMo8fHILz2EhmbcqPpAcGBMqRC8fvpl7db8c6sbU4y34DfkySzaDIOVbOOIqnryBq+juKQWDFccTEo17j2SH40dSebq3oT9k35ghq+FD6j/GpDu/5PdU3BfQNhfNVb+mwBZRHzIDAmiWiK+//ctddI4HgRtCEtakAYakrkb4sYGhVa8Kg5CAL3XBzS3893DEF3sEr/EXIm8qLFObSq53OSRczchSkKSK0lW9rQR7rGIojRFOD7WBkn1HLrqnIFX2EzPCbn1W7qDACZwI+tN1w4b0IpJVPn6BjUmDd0gHh3L8mcsvHcFAVjKPp8kOuieKWJ2CdSzWCQJ8gOadX0YvA0x7CO4BLhpce78CYY4AgBmgUBy5+JPxfkCAQtIAZzZ6SSgmCLTA8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002857, 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 Wed, 13 Nov 2024 14:42:29 -0800 (PST) David Rientjes wrote: Hi David, Sorry for the late response on this thread. To be completely transparent with you, I am not someone who inspects hugetlb usage on a regular basis, so I may not have the most relevant insights when it comes to how much utility there would be from breaking down the usage by size. With that said, I believe that over the past couple of days, there have been some responses on this thread regarding how others use hugetlb. As you know, I share Johannes's opinion that if there are people who would benefit from splitting up the hugetlb usage across different page sizes, it should happen in the hugetlb controller. > On Mon, 11 Nov 2024, David Rientjes wrote: > > 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? This is a good point. With that said, I believe that this is an instance of a feature where both of our proposed ideas can co-exist; we can have the total hugetlb usage reported in memcg for now, and if there is a consensus / majority that would like to see the breakdown as well, we can introduce it in a future patch without breaking the utility of this patch. To quickly address a potential concern of bloating the already large memcg stat: including both the total and breakdown wouldn't be the first time a stat and its breakdown are both included: there is a precedent with this in slab_(un)reclaimable and slab. > > 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?> This is true! I still think it would be nice to include the total anyways, since for a lot of people who use this statistic (Nhat's response in this thread and Shakeel's response in the v3 of this patch), all they want is a quick check to see how much memory is being used by hugetlb so they can reason about memory dynamics. Again, I think that if we are to include a breakdown in a future patch, it can coexist with this one. > Friendly ping on this, would there be any objections to splitting the > memory.stat metrics out to be per hugepage size? Sorry for the late reponse again. I think that if you had examples of use cases where having the differnt page sizes, it would help me better understand a motivation for including the breakdown (I would be happy to write the patch for the breakdown as well if there is a consensus!) Thank you for your thoughts, have a great day! Joshua