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 06864D68BE2 for ; Sun, 17 Nov 2024 03:34:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EA499C001A; Sat, 16 Nov 2024 22:34:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C1D59C0018; Sat, 16 Nov 2024 22:34:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6898C9C001A; Sat, 16 Nov 2024 22:34:10 -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 4AB859C0018 for ; Sat, 16 Nov 2024 22:34:10 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B12FEC012A for ; Sun, 17 Nov 2024 03:34:09 +0000 (UTC) X-FDA: 82794166476.08.53EB37C Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf23.hostedemail.com (Postfix) with ESMTP id B8CB0140004 for ; Sun, 17 Nov 2024 03:33:36 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4YbCKDTU; spf=pass (imf23.hostedemail.com: domain of rientjes@google.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731814389; 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=AOX3KyXD/eJJAjnkxJqzzYE8mS/sgEW7Z5FSy4P93gk=; b=1PsalfLHGjzqaSsrk+g1sWVCbl0n9felwqZabPOGej9eH2fMTra4al8NBrmgd86qwlI2Nk ldQRnR8Vz0vBKBniyvE8/vDYbwoKLtqnzj7MYdsscr7QOS9h8xBSgQEawiaOdFEzl1jssa o9TLnT9WE6r9BQIpAeMZWDDAHgD1QxY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731814389; a=rsa-sha256; cv=none; b=vs5vXScMT553Qq0FNdMllCwgJHGFp4ZW+nW3nHA+bgKh/SX14mDCHlcnd6DuQJCnKQSnQg fN96IkD78cKNDyNYNNq2cwM95IH0r9waXSbSU6CZq5Of2QbK0LrJulCXmj5Gb92727OPKK ArdYmCTk4tTLNE8geENbarVsvnDyOiE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4YbCKDTU; spf=pass (imf23.hostedemail.com: domain of rientjes@google.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-211f1b2bf2bso90065ad.1 for ; Sat, 16 Nov 2024 19:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731814446; x=1732419246; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=AOX3KyXD/eJJAjnkxJqzzYE8mS/sgEW7Z5FSy4P93gk=; b=4YbCKDTUs+jBIXKtwkWGp7aCc3u68IPjGyHvqyAyLkMO/NCXpxVee5132CxEdKV85U JMarA77BH+yAXjlUUF3qUBhfDEPYBbq7btM2Bq+ECacbgn5/DFOYm9pjkDojtbyVgejl GomFcQ/7DxK3bBZTMXB8VqMk0NEVQE1H1s+3OqJtfofR8vtclHSmnfwOu2zhEECIk3F6 TkwnA4T0ySTX4Ul04zXxbVhpGRa3TkC6lWo514SyK27ShKgwifuvz2ri7r4sz9QgFnIX rp5eebEljpDNc9ezNNbtS1nFyWDGy/wxemHXl/AqQqax+hfgW/AVjCwMxDD4dJzrR9tC HOOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731814446; x=1732419246; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AOX3KyXD/eJJAjnkxJqzzYE8mS/sgEW7Z5FSy4P93gk=; b=XKUkccokvlX2VYH9sG3OWoAaszTO06x7OUAaREljhktAtdHQpFP+3HqidWKaaI8XpA WcZBVYlOSBe2Ewh0+V3+BCF2YYJAg3E6Xj4EW4Ui723+rYG2y/ZnfCTGdBx+LfXf56wO cZSfr9726FGlpu1qUa4j6LXTvb8Om4+Eb+tfefa1lhntEsnsEz9ARQ8HYmjSQxolaNv5 TpJoVhT5WMpwX++/plTvsLf3XcsnVXdq3L6v1nzJsRCrQsqPI/NaCKtIDZXJzEbzwfCI o44fOJPMqxkpElNBZ4yLA2Ap2OePRHYuLKXdnbjDF6VSQN9mZUyifTCD7n4xQejsBflu gPsw== X-Forwarded-Encrypted: i=1; AJvYcCXZoe4JOkHwQhJ/unINnj16Cjoud8D9VIIu367d30TMN2i+r8zG+IyUKS3J2SFIPBoLqYZBJILJ6Q==@kvack.org X-Gm-Message-State: AOJu0Yx2hip3TBD8gi+7FhteCv+94jqxV5ZQ9fIj3VRx9FUQVv6CsEMf J9PaLp8r6shdqLbwz3+ieY1Y6XVurJ2ltTisNdZXLJyu0Jn9vMEZWs6ouF9y6Q== X-Gm-Gg: ASbGnctcbngb9FJcmt+T7M6ZrTANxmrTxqH8CAZr0fhRgAQHj+JwHGVMFmDgx8B5CG+ cuRwC90g3m7r64IzPNeoLheraWRJj8mFAoyab8yaUhp5GehHTLCkuLbXHJ6wj+m1hB0l/1PavM2 YuIqAqXmqMM2pTQcdwuOmX4p5u/21R2Ro1fzIDkgkHP3st123dLny/p7Vek5Wr3x+3MK59m9zlr Gpz9YnpYlKaZSkBUGL+xg58xfEVYr0jtPD1y3vcKv3TO+r37m4I5J36Jeoe8H8J3asnrJ6ZR8Wl Zg== X-Google-Smtp-Source: AGHT+IGPoixMjPOc/jgNWCvbrikf5QKqxsGFrmaEsXlgsR6JtxYUwWpc2eNtXOXeVrmypR6sxs71JQ== X-Received: by 2002:a17:902:c94b:b0:20b:bf5a:c8 with SMTP id d9443c01a7336-211ecf6145cmr1959885ad.10.1731814446065; Sat, 16 Nov 2024 19:34:06 -0800 (PST) Received: from [2620:0:1008:15:c1e1:2e4:c82d:76a6] ([2620:0:1008:15:c1e1:2e4:c82d:76a6]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2120dfab3c5sm3500375ad.22.2024.11.16.19.34.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Nov 2024 19:34:05 -0800 (PST) Date: Sat, 16 Nov 2024 19:34:04 -0800 (PST) From: David Rientjes To: Johannes Weiner cc: Joshua Hahn , akpm@linux-foundation.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 In-Reply-To: <20241114052624.GD1564047@cmpxchg.org> 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 X-Stat-Signature: j8h863frxze5xfdwpcwhidxop6sjjqo1 X-Rspam-User: X-Rspamd-Queue-Id: B8CB0140004 X-Rspamd-Server: rspam02 X-HE-Tag: 1731814416-873345 X-HE-Meta: U2FsdGVkX1/rQM/xbBf7LE8XNGeVIgKWtpeUt15CN8xhS8eGiuUobpL128uS8PRFHuZ1VAWA/K7AKBsZGxgIJkyqwvilY9YqUrxoD+GEz+lTlEub0/QbFqdc5b/425eVQlWffY6pfaKzmtv6Qu7U7X4AWTRy9EnuFuCGRoJsw/yE4ZlUsAVwVcxZAH3xmqnubgViqKmdT7wzgbMFgeJewQiUmMDC7IJINx04Hk1pqT/ewfR5CQOoQO8UpU1mIzc/laXu6LxG3c0IJAyd4pD96GqQpkZXDY9E2/TpvlOByngtdGpSEEOqKCl+JFZA2iQ0Zmez/3Y9EvM5l3blpp2qYUbvfj/udSZ5q4NKnOifGkr9ksCXKXwCWrgC1ZNElqVNCQJCWpA0kuDpcM3mK/ofR6WAVmGX8xQMsFJd6TM0NlIIIo0yekHlD2QeKgFdoF21jbJaQHaVTOew8lI8LpQW2LaNTEFftVP0hcAbLVARKp+SkntemGHOi2fZZT5eYI0qNH/j0IoqpwJKFZKBuz+BjvwHbCt3ZckQlHoOGaEhZWA4PncmuF94sSW57nZtaSSUsb1DThPBD6FXzy8egyttv0w1e8uN/6mP8/t+V8plKKhGr/UX7v7CYzMCAy3153DSCDlhZnALXkElU+uWe8aeLvgH3EJFwaedg0Gna0NqxiHNV78cJH0NlcDtVvTUxqldUHlFhUgZ1kVt86DKPKVal5K06c1ve0AnGOg0eVxAGmPVUJTggx1L4NBHxcwUmd9V8iWc04+29dmkl5fcGCX3eJe4N9K1ZwnqEW4ozW/iIJxpQt0qejAjtD/bMdmLM9dYhQh1BpZbn4D8YgDeu/t4FF0FZY2KTHNUudBwkMZr+sGywIK/IaN9S2mzavYP6vkRbfLWICFY5byHvvmdL9g7cH56U3Rgkoi/xI/p7P9oxj12FDnhncjsN3tPy8HuzAVVPBDeM+eeaphn7+wvZJR 6qPfIFQL Hqi4ontCbuLOGPRaZ2sViBNPjXaixguG9rzhw0Fcle3osQfV4xmAJ5FG14/g6hcGGIzxkb8Pbq5WmngNGK1iy7DucfmJpR6C8FAXN1iPZrTl3Kx7aFFesp9XC5h9elPCR+IYrK60F7nqbQ44EnEg/stXbxl2aLr+f1iPFdRFK0+q+702/FVpFKmge2l4O49MoGHSiJVujTTfH2aM/nOqN7INtlKAQvWawmB4kOrpHVuX4wFO0alsqnor/OcHkfNaVYOADutQUSgje/XgOfMN8SyDgElLe/cXQ4Kx9Q0yJY5BWkvIOFmnylM/XXk9VatBRsUVCdZeCxO08Ugpe9EQM/dpK2S7XMJmVyZy5u2ltvvrkabEeEiuQNOJ5qjFfrv2jLZfq438iI0N9GOOyriV5E5LCwky6TFx07LePr3lYQ1PI4MgSi3WwhewbX+R4rHOvYf7G 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, 14 Nov 2024, Johannes Weiner 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. > > From a memcg POV, all hugetlb is the same. It's just (non-swappable) > memory consumed by the cgroup. > Ok, that's fair. We have a local patch that tracks hugetlb usage, admittedly for all hugetlb sizes, in struct mem_cgroup_per_node so that we can provide a breakdown in memory.numa_stat because we can't get the per-node breakdown from hugetlb_cgroup. If there is interest in that breakdown, we could easily propose the patch.