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 827AEE82CC0 for ; Wed, 27 Sep 2023 21:38:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDAD38D009F; Wed, 27 Sep 2023 17:38:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8B038D008F; Wed, 27 Sep 2023 17:38:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D538E8D009F; Wed, 27 Sep 2023 17:38:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C206A8D008F for ; Wed, 27 Sep 2023 17:38:07 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8B55B40D41 for ; Wed, 27 Sep 2023 21:38:07 +0000 (UTC) X-FDA: 81283690614.29.CE6F261 Received: from out-201.mta0.migadu.com (out-201.mta0.migadu.com [91.218.175.201]) by imf30.hostedemail.com (Postfix) with ESMTP id A7A5680006 for ; Wed, 27 Sep 2023 21:38:05 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KKIpmjs6; spf=pass (imf30.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.201 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=1695850686; a=rsa-sha256; cv=none; b=NbQkSrmd4LSYbTo8SlQdWuhM7ZK6xuPHHKmewEDDOR64wJ6dc8e5Hg3n3M0tBT/Yotu2ZS vbsjcXdon+1nVPdO8NG/tDMXqmuUEdoF7+4ZLIPdULrE85haRxp0tEOubAnC6BNM/WggHH 209wn7axgLAnEdWhE/hCJez8hTp84Y0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KKIpmjs6; spf=pass (imf30.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.201 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=1695850686; 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=Fue+26Fi7AotWRkg3AT4B3mHGA43i1+EdYHYGE/Ep4Y=; b=nFcVjq4SsKih0PvU4sQr3HELIyKTBNgnL4PZktIFWUTPn1atMRz+8LEYXMPfkTAyr5MrI/ ojbJAjGCf3SPBMTToYY3pWhK5tryKNwls5Iu0yY1GBSe7R9VFBsg6HI5MIJ2dmhC2+WqOb IB9ZHszZFdyQ2C/U7TptQBIbwGb0+Ao= Date: Wed, 27 Sep 2023 14:37:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1695850683; 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=Fue+26Fi7AotWRkg3AT4B3mHGA43i1+EdYHYGE/Ep4Y=; b=KKIpmjs6N2RDl4NoQebosFZc/837RlU9Q67hiMiiXzWdf8Ho9dWsfnrAZhwHmYazDbIVIc 5MThELoMpe7+7DOttUKIcQjnYbyC3R0i+uvwLgpxT0H3vhysicEt9Zz3rz+6MRCSp45NZG bITBCQdsIGuUN5iEPoPt2o4bmYasj5c= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Johannes Weiner Cc: Michal Hocko , Nhat Pham , akpm@linux-foundation.org, riel@surriel.com, shakeelb@google.com, muchun.song@linux.dev, tj@kernel.org, lizefan.x@bytedance.com, shuah@kernel.org, mike.kravetz@oracle.com, yosryahmed@google.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH 0/2] hugetlb memcg accounting Message-ID: References: <20230926194949.2637078-1-nphamcs@gmail.com> <20230927184738.GC365513@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230927184738.GC365513@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A7A5680006 X-Stat-Signature: 47p64t66zm7mgwt6cwtxguakz6xsiqz6 X-Rspam-User: X-HE-Tag: 1695850685-110162 X-HE-Meta: U2FsdGVkX18vA1PlzHljGT+ShLPQd5RUHTCigMhP+vesGLKduce8v+qP+exWvaG4TOFf2u/n1ZO1rzeqoR0QWH/SKO2ciXp8hK8f34IbV+wCiK22UFlOLDZR1BPIr4bGNiyhLJtCtCAqqdFU03m29qkJSW5kVeyf8t+A1d3I1G0Lojao+EZyHyzRAjEz1msa+y7urkNn9YMbqWP9nDAFTDH4ofXlYO0xZYlNFQ4x82Ovpar120NrNcIsSmSzIaEuR/pt7S9yTa6R9PiyLFZ0/4jhEG8Y6sXYEm1OG2ek6R3yAlYFsErXg9JewE9Bqyh++A874yLQ2VodyN0sMVKFbD8BebtOVWcBB3zB13SuSF119i0ZipHgyJGN1Y47wFeuS4z0u+wg7Gsz4Jv+nrrfdMU+Hd3PRVGG9QOUOE0keftjb+pJJwpMMgTkE1WtYXaOGarxz/y0CznR9q0SIaq0188Hss0m45rc4PHa5hH45CD5YrzvcS2TKJ5KnKWby85JE/e4UrEKyrE843z5Nl0CQtmdyl6oth0qJmavcmipqFHumNgvME3S84HlqO2k0Ip2KG2qvI6XivmWLsLn13zC3GYLSnJRgX/jkxMVD/fIuX4CHp1h8i4UQ7F9FM9awV1WAQC3kBLARhpo0hCajDy4vyjwLjxg3Wt5Jxjk4M/uGXwasoc46syDlGkdYZIaGIFEhrXhvwopP+tkUqgLlfPce+9VmB6HW9D4ESANxELfH3S2eb7sn/991XBjZjQOxhYNn9t4DwtYt3j4FhfAeJ2Aq7P0qzEZ96DRm3hCLHpkokNgqFr9E17GIUc3PgDusR8LR5phSICGM1p/8gRY2rjFnaXQ4p610taJdjLH/Q1VwXx0RxboBsHqpYtWDXBjoAVmQeX/+SvF07a8i5qWTda3yjSdFvlye2easczGw9KeFKZKrhW1ugDhRHpygNvewDzkVSvCCdJcKwadp63Q7KM jdzqr3Gf J+aEHwfR7mkPYuzJmx6JqGgvP/Ixe2z5H5G74S2Ehy8poH+JzdCsc44sV2GjxikKOOvBSeX17Qmw2NSIw/o4EA76TUCgUwIWTsH3c6Bu3mCJ4NkcQPG4wqPWGoO4dXYrhJBRzmmek6LkUsnw= 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: On Wed, Sep 27, 2023 at 02:47:38PM -0400, Johannes Weiner wrote: > On Wed, Sep 27, 2023 at 01:21:20PM +0200, Michal Hocko wrote: > > On Tue 26-09-23 12:49:47, Nhat Pham wrote: > > > Currently, hugetlb memory usage is not acounted for in the memory > > > controller, which could lead to memory overprotection for cgroups with > > > hugetlb-backed memory. This has been observed in our production system. > > > > > > This patch series rectifies this issue by charging the memcg when the > > > hugetlb folio is allocated, and uncharging when the folio is freed. In > > > addition, a new selftest is added to demonstrate and verify this new > > > behavior. > > > > The primary reason why hugetlb is living outside of memcg (and the core > > MM as well) is that it doesn't really fit the whole scheme. In several > > aspects. First and the foremost it is an independently managed resource > > with its own pool management, use and lifetime. > > Honestly, the simpler explanation is that few people have used hugetlb > in regular, containerized non-HPC workloads. > > Hugetlb has historically been much more special, and it retains a > specialness that warrants e.g. the hugetlb cgroup container. But it > has also made strides with hugetlb_cma, migratability, madvise support > etc. that allows much more on-demand use. It's no longer the case that > you just put a static pool of memory aside during boot and only a few > blessed applications are using it. > > For example, we're using hugetlb_cma very broadly with generic > containers. The CMA region is fully usable by movable non-huge stuff > until huge pages are allocated in it. With the hugetlb controller you > can define a maximum number of hugetlb pages that can be used per > container. But what if that container isn't using any? Why shouldn't > it be allowed to use its overall memory allowance for anon and cache > instead? Cool, I remember proposing hugetlb memcg stats several years ago and if I remember correctly at that time you was opposing it based on the idea that huge pages are not a part of the overall memcg flow: they are not a subject for memory pressure, can't be evicted, etc. And thp's were seen as a long-term replacement. Even though all above it's true, hugetlb has it's niche and I don't think thp's will realistically replace it any time soon. So I'm glad to see this effort (and very supportive) on making hugetlb more convenient and transparent for an end user. Thanks!