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 95342D30007 for ; Fri, 18 Oct 2024 13:42:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 028036B007B; Fri, 18 Oct 2024 09:42:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F19246B0083; Fri, 18 Oct 2024 09:42:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E08546B0085; Fri, 18 Oct 2024 09:42:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C4C896B007B for ; Fri, 18 Oct 2024 09:42:18 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5894E40370 for ; Fri, 18 Oct 2024 13:42:11 +0000 (UTC) X-FDA: 82686836946.04.AD3E3EA Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf21.hostedemail.com (Postfix) with ESMTP id 05E2F1C0003 for ; Fri, 18 Oct 2024 13:41:54 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Rr1NWh0C; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729258861; a=rsa-sha256; cv=none; b=LRnzyVSjx8uXVpzMRm2fmCNOdJHIsgpcbIuEOVd95CVcbfJm14BryRPYLogMF/7OCJF5ny Ui7vLqmdBlo1780IesskKnxfsm/qr7ZadPe15xSSUIrecMWptD60A7CWcmbibSOd/BHmAs zHWsbwBwTg3a+A169yccaBtFp58Hy14= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Rr1NWh0C; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729258861; 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=HZa7Ue1oIcLGAigjL4zuYAAZ2xEAi56JLa+QFpctN6s=; b=zJozi12kaB+5ObWTfpP3ZaeYz10B03pv7h9kzVPSMwRwhfVxSNRL5qUhCAusf6RWnSUW44 z9gOHqEyTlMJA5Tjdq5sFygKS+zPdZoqDbRELd3j366MVccuyYYoCXxK14hYcrVIogjSF9 wkOEZUYpvgYKXXfKUrc3b+ukKgZq2bM= Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a991fedbd04so135378766b.3 for ; Fri, 18 Oct 2024 06:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1729258935; x=1729863735; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=HZa7Ue1oIcLGAigjL4zuYAAZ2xEAi56JLa+QFpctN6s=; b=Rr1NWh0CV7CD/fhu8Ib0q3DBL7kfFnWMfaJGmylPXZGINGiZe8Kutc4pP8055GgR/F wVCXMsfp5L/D5SfEjGqQ5gC8GAAsjsG9hxK+NH6ZxcNxaTmuudz/lCZJi6ccTEgJGyCS CilyzaE4vpQha3U8DmP6iR7+4qUmgkriD+MGQu3U4vW3brY5toBZ4KpNdO7fSzrINSNw GXBA51u1iLq6gyL3Bp1OQesx41+n/zu5Vp/Izo5Fhv5DLNEeL9E/7KymHm3cY5Vjt7B8 n/SK7SS+vjWmRXTSZ0agIe9HXaUEhUeyDiAmi16Z4k6l7XCbRQrVI+I4NlGYgCdaMApv zh4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729258935; x=1729863735; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HZa7Ue1oIcLGAigjL4zuYAAZ2xEAi56JLa+QFpctN6s=; b=Bn5Tsu5V5CxDlsYnSkW4tX0fmEQw7jLKF8cX/QLsTbjz+RJKcf9ACBNltVpbhnjSEo Rdr3smNoyNhQfkoNegkORDWJY8ogwUvlFav5lbi8wnf9VB4/Q/b6fZGuyUQcB+kgyTgZ 5D2kdL6WWrlfLwu3VdbEoJ+p0OJE297hQWWu20cFkcURbtuh3O4/6Eq0yLWZa7mZ8+4W 1Z0mM8GC7KlT7jIfawuok3zomv873B1KOpvd3GlWoQpE+CYtsmXWzQqmZAd+u9cDUR74 /YmR4q3M0Ya/tFTVqt4oj4By3b4xaSeUAwMfzMG8cjVgZXO1erW8NGGjQO5G436/boLk Cb5Q== X-Forwarded-Encrypted: i=1; AJvYcCUKeroxY9gEWDgNAzBDAnpqioITtrDDRio0Bc87lzBxkwL7nsCFpoi5hm8R1d+jQK84r1bdB/fzIg==@kvack.org X-Gm-Message-State: AOJu0Yz7Lg1eJVIDidyeGT0RrUQJYX2Pa3/nQ5E3pju2T03b9MeXIt3B WnzVB6Tr1lBNdGtsDANS4uWS4bMs8lUEggPk9kg7lsDBcZ14WLX1nGxpwAHYV/o= X-Google-Smtp-Source: AGHT+IG6Fxgb4NHCkIX3/dnlPvjFLsVzKH6Jek9DA+hqFWFwOWxceGjaQg5r7AgnL5NBc1jgnzfu1g== X-Received: by 2002:a05:6402:274d:b0:5c7:1f16:78e3 with SMTP id 4fb4d7f45d1cf-5ca0ae81acbmr2408464a12.22.1729258934653; Fri, 18 Oct 2024 06:42:14 -0700 (PDT) Received: from localhost (109-81-89-238.rct.o2.cz. [109.81.89.238]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5ca0b0fec43sm751287a12.91.2024.10.18.06.42.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2024 06:42:14 -0700 (PDT) Date: Fri, 18 Oct 2024 15:42:13 +0200 From: Michal Hocko To: Johannes Weiner Cc: Joshua Hahn , nphamcs@gmail.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, lnyng@meta.com Subject: Re: [PATCH 0/1] memcg/hugetlb: Adding hugeTLB counters to memory controller Message-ID: References: <20241017160438.3893293-1-joshua.hahnjy@gmail.com> <20241018123122.GB71939@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241018123122.GB71939@cmpxchg.org> X-Stat-Signature: onzhq6d5upfrqubowzuf7zw8d9yg7rzf X-Rspamd-Queue-Id: 05E2F1C0003 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1729258914-834573 X-HE-Meta: U2FsdGVkX1+Sod2ayOI4FrMVK95eYecFmUlu+sj48IudsyAfMkzNrx9E1sA98GavBOKRobwKx+GYPQu10ijEYzP1OViKc9W61HMiLgMUhQLKl1QXFgqDrkDP4xkVGfSacwiNVcN9+i/n67B9AcXoU0sMXPkebInXfMAIWIjEYsfWcRAt5gyioZwPlkm2rdXlnv7X+aT4wzv8hS0BdGIl4Q/PLmq7ePEW+RtY3KaIiNVaFrbimAljZtfFEtyNYMqJjGYTbx7Wtap5vLtjcYwkO6VuzUSAU/ELsNZrn9wZF6WNgNVTQeS+etNOWXfRdI9LEj3vX1iayOfie5qXUWoWMlDzJr2LVHBQH9uIAtm5KLDddqiSz2VoqutF0PYg+uB0e1f4U2gz6g8XJfvRf3JNBwgL/vznOoBRBE3/w4KViDkrjfTzQpc6TsS53O7u8LNc5t4j+6SzESvTw9HdOVlxkl3T1PtdzGfUka5tv4vS0ZQ5Hi67PK6zQNolMlN0UJY86owJ8o3gfxN6XMLQHBBo0A44XcuQc5n00MwcU62dyaf918KQ3H+LX6b6G5CmH/6lH4Qk0vjAxzct9dcKuaT3moqvd9EOKeNfTWbZd0tQiDOVVukJA0ksd9IjChXHXn1wUasLrWOFASabi6bNic9bBJgAIBei64faY7OELpw+CjbI0Na89ASx3b9bwOlqS5EtiU+ulOfq0MiUf3DRS9K/auIcmwlQsA8WhRAuCThAEMafLyOuikQmUl8Mw5gDqWyzYk8ot5vE5TLmFLnam0botOiwLGwm+9tzPC6KHTFsIB2YThaPUkfeq9WOEV+8cLSvQxuSdlvaEBga4e72OEqbGJtuUR1ksrS3k7Sq8N1Jy88RlWy/PPcZkV6536TzArcJpvnfRYwpRpUpti8lvNPRNh+9Q4OC59GFLNoTHHHdgPhWr0bJzkwqxy4qp8d7SjDWbXT9gDquaqdAr4GnvRN OMxCEocM Six7nlMq4312YIGCaizN6UN4SPqrre0ma++n07UP3ccEDsedikI6Up8qroUI+zVdM1KYhjmwm/WlRnuGMqzOpP8sn4EgIyhqtopKW5DGUdcAzR3g4nefaIJxQFk/uV1SLOsvZZGUVjqLDSYe94TCHRVDJA17MuL34h+coma6QuuyFPOYfDuJP7WZ5XtyHmokjHIUleCuNRZSjSe2R2dal1lXRmIAcrMcFEBndLrjkCnciPHkSvQ647Go3NqRHF8oWq7GIxif68Hsr0wlhUs8u/vKfzZ0FMlvo8ZfjyqMzn2kRGqdGrDK1EfpYz16HqmVYcGo3oShg+NyqMxl5hgQVPtu9/E+j0hWvQDJGMSnh4Xv7P+6ZR3VpeY/AFy7KGoZ1pd5h 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 Fri 18-10-24 08:31:22, Johannes Weiner wrote: > On Fri, Oct 18, 2024 at 12:12:00PM +0200, Michal Hocko wrote: > > On Thu 17-10-24 09:04:37, Joshua Hahn wrote: > > > HugeTLB usage is a metric that can provide utility for monitors hoping > > > to get more insight into the memory usage patterns in cgroups. It also > > > helps identify if large folios are being distributed efficiently across > > > workloads, so that tasks that can take most advantage of reduced TLB > > > misses are prioritized. > > > > > > While cgroupv2's hugeTLB controller does report this value, some users > > > who wish to track hugeTLB usage might not want to take on the additional > > > overhead or the features of the controller just to use the metric. > > > This patch introduces hugeTLB usage in the memcg stats, mirroring the > > > value in the hugeTLB controller and offering a more fine-grained > > > cgroup-level breakdown of the value in /proc/meminfo. > > > > This seems really confusing because memcg controller is not responsible > > for the hugetlb memory. Could you be more specific why enabling hugetlb > > controller is not really desirable when the actual per-group tracking is > > needed? > > We have competition over memory, but not specifically over hugetlb. > > The maximum hugetlb footprint of jobs is known in advance, and we > configure hugetlb_cma= accordingly. There are no static boot time > hugetlb reservations, and there is no opportunistic use of hugetlb > from jobs or other parts of the system. So we don't need control over > the hugetlb pool, and no limit enforcement on hugetlb specifically. > > However, memory overall is overcommitted between job and system > management. If the main job is using hugetlb, we need that to show up > in memory.current and be taken into account for memory.high and > memory.low enforcement. It's the old memory fungibility argument: if > you use hugetlb, it should reduce the budget for cache/anon. > > Nhat's recent patch to charge hugetlb to memcg accomplishes that. > > However, we now have potentially a sizable portion of memory in > memory.current that doesn't show up in memory.stat. Joshua's patch > addresses that, so userspace can understand its memory footprint. > > I hope that makes sense. Looking at 8cba9576df60 ("hugetlb: memcg: account hugetlb-backed memory in memory controller") describes this limitation * Hugetlb pages utilized while this option is not selected will not be tracked by the memory controller (even if cgroup v2 is remounted later on). and it would be great to have an explanation why the lack of tracking has proven problematic. Also the above doesn't really explain why those who care cannot really enabled hugetlb controller to gain the consumption information. Also what happens if CGRP_ROOT_MEMORY_HUGETLB_ACCOUNTING is disabled. Should we report potentially misleading data? -- Michal Hocko SUSE Labs