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 EC259D637CF for ; Thu, 14 Nov 2024 01:08:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 815D66B009D; Wed, 13 Nov 2024 20:08:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 79E656B009E; Wed, 13 Nov 2024 20:08:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 618A56B009F; Wed, 13 Nov 2024 20:08:39 -0500 (EST) 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 41A816B009D for ; Wed, 13 Nov 2024 20:08:39 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B9F90A0E35 for ; Thu, 14 Nov 2024 01:08:38 +0000 (UTC) X-FDA: 82782913836.06.87EC540 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) by imf08.hostedemail.com (Postfix) with ESMTP id 0380C160023 for ; Thu, 14 Nov 2024 01:08:07 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eunzyUGD; spf=pass (imf08.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.178 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731546373; 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=R02m2/PelGWyh4Sv4uylgE9NNrM34+dXsHobBN6dLU0=; b=uZZ3qlyt/+XgQwNd3p+nR2UZzyOZr87LsZE/TfL9qgM5giOwqVfOLCwCWNg39RkMaUXGDh kYYjXdddNNsPL4TufadNTeTFe6ESBt6iKaBt5CKoAVoWYaO32ky9PzVgop3NgoDpexiLuw H7HIANkmXFQ9xGVkZyIev3o+H8ZhxOs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731546373; a=rsa-sha256; cv=none; b=jdG3ccxKeUz6zJ9TdrZWrDGez/J9rCkoSWBXbphnkReFuDqtgVXEbvMTUpk1gMWxM4Olbb XzhHrLwRJQhGr65H0Iryk8mG5V2ozJoYjWT312ZDN6KpONgxu8ab8Z2SvDXSSX/cumYST+ IC8s5/WOIrK4ec4wWKKGmuZxyiE0t/k= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eunzyUGD; spf=pass (imf08.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.178 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-7b35b1eb7e3so19804185a.1 for ; Wed, 13 Nov 2024 17:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731546516; x=1732151316; 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=R02m2/PelGWyh4Sv4uylgE9NNrM34+dXsHobBN6dLU0=; b=eunzyUGDKcDtGbiCn67gSmeiT8wCeQmJoxIQo2L9zwXJf+kCNxMU1QaEjcu8rA4ynF eQCZoL9sFL/BHWfKPd+IR+64BILOvHaDNmGp1lzYPyWnJm2OGYjSSCUTrUeSDG2Eh+vs GnLNXNIYtVvIQtLsh/ge16oDAagxN5M3fJvUA03QNBbVq1iD3sGF9rrYd/dlRbZ3+qIl dAFsxnfuBmCIJ+86O6ZSyTsc/BCHeuCo4AU993dhLT2B1sUpeC0ibc6gHFE8cfdEY/jM gzO9y9e8hutuUWBJWBazEfRvV0f5iui7H4lbi18bPWX7I/kVXSmjhPFk0VKQMv7+vHBN +tOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731546516; x=1732151316; 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=R02m2/PelGWyh4Sv4uylgE9NNrM34+dXsHobBN6dLU0=; b=K9daITO/4pOCNKzlAmMvrq3alJ1xezpZfMxYhTP+KwTkwgXdH/XUXiQ9rrcn6+hM2e YnsVoWvbFeHmcXqj+UQuhJzqqUSKUwA59UsgpR338Fa310zqwd9BBS+1a6KJTUL9yO0m S0O2cYW0WKjf9b/S3m+QZ+/jUWfFEeWM7iU8gODzedM8wnPdn8nffT1fvipQ5hMrg2ld pVL5bSRe5sLW0JtfB/XFThu14MfKDtA1N0H+uIGTrS+Pa/UiTa80Bm+RElM5Y2wDBaQQ PEx/qB2AFlXh6IBfiGSP7YxZDslqWsrWsXqbUqSzO3OYe0s4aOmDhfy/nT2SeiudMbWC yOnQ== X-Forwarded-Encrypted: i=1; AJvYcCX+GnzKfowRDLzX4SQW/gr1YkZqeikPM/UBVc+v89cp++bqr9kD+udS9lRE+j6ILpVW/ZPPhTudvg==@kvack.org X-Gm-Message-State: AOJu0Yx4mRZSR2MUI7hv46XsI5pAQFucfg/UiXloDql1HFYyMcUR+oCs yJIGXzhgML67jVXrXHN4BZuhWJvihIeFJDhX5Hi9fwj/Jjt7C2RidCb37+/Gv2iXQM47R8ah4kg tMSqwPeJbGYwvC2aqz5DUrDbfFiM= X-Google-Smtp-Source: AGHT+IEgPDHGyVD1YssYLJPhmEb1jN0TgpcCBY1/m117XlF1I5wtvBlc9bPf4LG2dSE/qJ16oCn/B+tUy5SyhYIG3UI= X-Received: by 2002:a05:6214:5d03:b0:6d1:6fae:6451 with SMTP id 6a1803df08f44-6d3e905d70fmr28857586d6.10.1731546516107; Wed, 13 Nov 2024 17:08:36 -0800 (PST) MIME-Version: 1.0 References: <20241101204402.1885383-1-joshua.hahnjy@gmail.com> <72688d81-24db-70ba-e260-bd5c74066d27@google.com> In-Reply-To: From: Nhat Pham Date: Wed, 13 Nov 2024 17:08:25 -0800 Message-ID: Subject: Re: [PATCH v4 1/1] memcg/hugetlb: Add hugeTLB counters to memcg To: David Rientjes Cc: Joshua Hahn , akpm@linux-foundation.org, hannes@cmpxchg.org, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0380C160023 X-Stat-Signature: r7137utpiw9n48upfie5d5syhwyh8381 X-HE-Tag: 1731546487-626370 X-HE-Meta: U2FsdGVkX18f2qCsHwImdiFVDjYRs4BiuOK9q0m0zQHEKoxJ6NINQdMOJEYHVdbp+8tF4hK0VGMGbkYjIJD+UMLp6HoqbJUW7wooE77ZiwN4wo29MTXBMAb/B/bgKy6j982P1LI8nDn3ib2+arOvngT6DXDET/M2CPb2KoZKo4+PeWT2l/DEvTn8qz77U4PNvLz+iWll+2hSsvkWDRhPRgpzf7rqzxKagmdiubgHz5FPBbuvnwtfwvh5H2jIE8CjB50n080SFOJidConyh488+hPnJRk+79ZJyd75AfZUesYjTTqpngXee25Vj5HYQctLl9MVV+tWFOq3OygHPkCYaLIxKmGLU90TGJhJq9Qz5NP/ovznPuXwBoso0YwlXPFtbs4T6Vtp07bjnvr+xZIOVd8pL4mBlZHCStfMPUr5x60ChuiNEgwLKM4QwNfsKpzZmVnPr+mTs1c6QPV5iB/WyyKWKoQx3E0G7lk93WEVVLmT+ye0sxIEWQmolY46vlijkyotQHXQztLYDIaUFf9KTHa9CnVSnwRU7BVq/SvzFGR12mCMnWtvx9kPpl/hr+BKQnhqtPEE065ipZWCY0D/UXCGbQfVHlAEW+cSZRw1zFIQqzedsoLIhSlsAC53jBeEpm/QVJaCfmfQwObtFFOpuqHmzCewRpcWiYYREIO8wy8Hjg1OjKk4/9eRcCZEuGmZFT79YU9oDlfri4tR+57qDjeHzBANzYQAIh5Ag+ercTfnrfYAk/fWEqZYUo5+DEfcHJK04uOBQTsO5vwZcryWSX1mvMez0idfvoZUnPamKTUZ8JPsGssJLJ9e6v3bO6MaICix8lLjK0G1OHLENNFx+TLdOnYYyhneCsfbrxzYPcReNxASkV4ZO9G9o1LfpRi1ajykWfgWoa5X5n2p9EIHL9Onc6rytOhnHJhRD/LE+XVsDrDSbXT5eTgiG7MCxYtyK6dmN4q+rpenFq/Gk9 5ZyjWHlX mPVrl+zBe2DrzKHvW/ZljaxWz0FSB4AAsVny6R74uJBH0hdbgR23PhAnEMKQfVlm0KlraDxDH7YFhQQiJefNwQUeDFyygfB7Y0CZbjrMdM2n3LrLVroDZS7txZyYWGHMvcylMnYC3Pa7ziVI38dV/BMl4iolrtdNd6cMnsZ0F4X1OksWruYYNV1uv43bxNPzmWIJS+c/BtVSc9soFeNomtupKBy+SegC2qYKP0L+kOR+UM7XNOQH2aUpzszt8r9MBgIFFyNEdREe5j6VmxngSl5phYMyKTpTIFExTBVpz9NZPqY9B7RdRfeMiy53N4vy38jYk3EjddUmODMNKwisoJLv4jJ5shKQL2yUgSE00VOqDMMBVxFRVfXj8w2pnvD15NU3kU01OvBNowHyMl4HLIqj9k+E5ZHFRp0YA X-Bogosity: Ham, tests=bogofilter, spamicity=0.056097, 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, Nov 13, 2024 at 2:42=E2=80=AFPM David Rientjes wrote: > > On Mon, 11 Nov 2024, David Rientjes wrote: > > > > > 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? My 2c is that it's extra complexity + overhead (IIUC these stats are hierarchical and hence would contribute to flushing overhead). So we should justify them with some concrete use cases if we are to add them. >From my end, I need hugetlb usage when I want to reason about memory dynamics. This is because hugetlb is a bit special/weird - it cannot be swapped out for e.g. So I have subtract hugetlb usage from overall cgroup's memory usage before making any analysis that involves swapping. For this use case, I just need to know how much memory is consumed by hugetlb, regardless of the type (2M or 1G). I assume many use cases are similar in that sense. Do you or Google have a concrete use case in mind that requires hugetlb categorization? :)