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 69FA7D3DEA9 for ; Fri, 18 Oct 2024 18:57:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E66226B00B3; Fri, 18 Oct 2024 14:57:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEF486B00B4; Fri, 18 Oct 2024 14:57:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1A416B00B5; Fri, 18 Oct 2024 14:57:24 -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 9CFAA6B00B3 for ; Fri, 18 Oct 2024 14:57:24 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 44F2A1A087B for ; Fri, 18 Oct 2024 18:57:02 +0000 (UTC) X-FDA: 82687630620.09.B1F0953 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf06.hostedemail.com (Postfix) with ESMTP id 17A5618000C for ; Fri, 18 Oct 2024 18:57:13 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=uKTrdgPD; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf06.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729277808; a=rsa-sha256; cv=none; b=HZTEZnvNzwKo2kjpUEHOM4WkhKuPq2fjJPkA0cNcpNIMxefBD9KJ4FWeEI7lv8/row24Fh g2vA/GsedgSp8thhvg7Sjo8Ua7JkvRMECcEXp3VleG0Vsp1NEE5Ug2bgIcNRBLAPwjcWSF NTop0fsPTLBGV659OwT8ZLmX6hDjdxA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=uKTrdgPD; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf06.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729277808; 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=s4xPE1nr+Xi0Dvh9jf2xWIR8MzeS9sAig5u4V7FCQVk=; b=UWPmjjNjAvNrL0yEUkLJmylajLAUG6jK/0yutZuHlnW4TrPQjpZbhAYYK2463A946X+4DY qtPIY55QfYOsKM3tm/+BYRplxjMYiKypuSiLr8Vf7gZg5kg9Iill5dtreeLzFclqDUxeJX G5IzZLcEQK4q10ASVe4DR0+44kTsHek= Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6cbd005d0f9so16174796d6.3 for ; Fri, 18 Oct 2024 11:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1729277841; x=1729882641; 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=s4xPE1nr+Xi0Dvh9jf2xWIR8MzeS9sAig5u4V7FCQVk=; b=uKTrdgPDPgdJ5PoH3v55Amgbf+AaDhsjct1JTVhZSsA6773c4sXrVcoBubjcHTPUT0 Dp/zcNHUtVUagMvlfrzcd5yP8/Oyp2qamOAlH+UgE/AuDQ6XRD+x/jSyz9xsowIbtzOR mI7gx4ijshDwQOUj9vdrbtOpQ9dk743Xjvw1FvNze//R596jbwuWfPa6ELuHy6J0oJVM UUUd75bJjDSUaEpAoj5cH+eZfIWotlOuMUqBXoUrU45hmlv8tr1YGgN0uOYxzpYyNp8L ZOXIPZQb0HWWIHZRMFMm5IKwMKlO8CWV2Ij8mFbzB7lKA/VhVVPoJcnyNBQShYP/pBvx ti5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729277841; x=1729882641; 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=s4xPE1nr+Xi0Dvh9jf2xWIR8MzeS9sAig5u4V7FCQVk=; b=J15+DxBgOo7l7ld/14jur2afPqno0OASrRTmIXNEXQExuUlKk50QoyfgQHtBs/EBGe MK6yN/E8AJYIMVhcHzKSyx3DVC0tz5d47xshgP5nMroYX4WHfwS6yH6cynxGPaKELqY0 XziT9iXvd1w7JsIFWNlyzZErHKxyFxsZIrG3EIyO9hIaSR8cDsIUSGGwNDJcI8j92jSG aqvuWU/gNQZfFhG3gaY2OrFxTmoBB+q+8c220q8lLoV1+KlzoXXisDwW610FLQYK2qY2 taB0hvE9zuE3gBHrP5FaNhnOXPX6ngW7hCanT22xtZSpW8e+bvTA2/6NnsaAjWg6GLk4 1Zgg== X-Forwarded-Encrypted: i=1; AJvYcCXl3GaRr1szFDpH/57M/SwATt0e8S9xUEvWrvL2WcEryKEDpns21xe2SwW8c8YcsU4jF/XfhZ6PVg==@kvack.org X-Gm-Message-State: AOJu0Yyg6mYI0Sk0lcQxEmM7z+cekECWhxU+p3nKR2sQG12Ex5n3lFOH xtf+5JjixOCadAgbsfjBjzzgM7DVyJD1riHqqLGRpnxewDVZdQAVY8Lu/dFzU08= X-Google-Smtp-Source: AGHT+IEuuGSdfEcgR68BP9v0JkgMFSUHwOyBoM4Mf66gDspCSViiSEAWC/C55KbM/GlLKRr9IvX+wA== X-Received: by 2002:a05:6214:4808:b0:6cc:2ba7:7f7b with SMTP id 6a1803df08f44-6cde1553260mr52975886d6.28.1729277840921; Fri, 18 Oct 2024 11:57:20 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6cde122a159sm9406996d6.100.2024.10.18.11.57.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2024 11:57:19 -0700 (PDT) Date: Fri, 18 Oct 2024 14:57:15 -0400 From: Johannes Weiner To: Michal Hocko 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: <20241018185715.GA81612@cmpxchg.org> 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: X-Rspam-User: X-Stat-Signature: krrbjn57r7ncgnpbog4fmg8rrtxtwzu6 X-Rspamd-Queue-Id: 17A5618000C X-Rspamd-Server: rspam02 X-HE-Tag: 1729277833-597786 X-HE-Meta: U2FsdGVkX18gsWAXA6wkjR1UCo1vPqztGOdHBMutP2MmytrDZIJf8QYrQv3t6nHsNC/SVcQI+uDHWcvcwqan08ig2L7nrNVdfKNYeLbayDR6YQSvkRAIanW/H8MDe82QQmoHZsUFSSVJeUZg1P0rqujPAZFAJmswaAofIHdfr94dD1f1QWqr/8xkRVVznsC3B+uqr2OcXPNxQhhvUPnNYeoYNdlVlwN2PM1SxA9k27cFosrHMLM7a5hUVvFlZusNjhboLBwgtNZmOq5oKehE020TKqG4Gr2k34fmm8KiiBkh8HIjjnL3MHzXdFW4jxrFJgK+Ql2a9NLVowwrp8cywXXSLM9OqhUWjRBdKuiKbOxJUVK9L4AYlcoCXW4+0jhVkF6+1qbo6WrCUeSF52zWCsX5Qg6tYkjuI3zy0F8cY87Kc5ZeGxXM/Zj9UFORaRTH9zgXcGR+wHnTMqJmICJOfDQ1hyDI0sT06fsFBZALTZ07Qo1RoThYcgq9PWeDI1AJeGJhwWwiVEKp/gBmO2Vn/GHFsYR4P8SqvT2+uf2PA4g1iPxeddzdrRpw2rPMOR8LBWnuxkxH2RbBfGLb9MmNf0qrCzzrPOnxP8txE9Rgp8gi6hFEpgxIsU9ggAQ8RM4TlOEao/yUg82TPcS1jROb1BBzJk6G+/NPdSIZntQe2mXzpxOxgTaCHPjRvGYRH4dIK2y0D0WwSZ3kSlBjgMtChBmGxJzN4H9DhBRXEVVEf2Tt6oOMHh2MFoFeAn0oci8K2JXqok5JvLn91XZPLCLycQIv+Y6DImFmpKp7qIWbzISdGVsgfsaq8GXMinwPRk8gymJkETRjZhF9HZTt5blZTajfnzgmvXbFIbebdAnnusvkomrt+RwUOVtCL7sPQa0ZR87DIlWMFUda2Mu9Qu8y70JV4Levp3fsn3sOmeZUXp/qhqT1TDwJphN1dtqdjD8XxFjZCANOdjKGbdkGIJW sS5i07ZQ KQyPtjY1XSPKsyQhCvJqUiY1NmREb23kqdyobliE6e2WzHGnjvmiJduOkQovD+1SpeXzoB4HF02Szioi0tV8ZihmX+VNkpOJUZ2EydkxvPudmiBvS0GzNxn8KMdPt5RgJ2x7jiOFiP7AlSanCJCPr8OR6H7Ptm29/ia4xXdDgjLQW67ngu6/slzB8r5j7K3oHwpcn81T97+1iGyJP9GtX9HKnY3LdYf9STNTXeNOXC8+UOKIQ4fAAxKX/+WpIh+h3U5uc/WVs+jY8Tl5fYqsClk/9GDA+T/YVJcQjvdi6zrek577U3H0l2i+GftpMRhm/N9v7FlkYxTVMebq/8LqNzH6Hub9l8uWcrvcQMXyb9Qb/c/j4/Sd1m3FLT1YBtoDd9FB6DXOfy9OjwenYcdZqtKDWVrRkM4P9ZvCoB8wvVRVv+O5qRPc+W4oyGaVG6u0lds7ZCsMEYuNRIQMRgf02RCZGfgZtPSGVbTG401LdY/dbwe76w4fWftBQM6hZGKt5N7xIzt4KZrMs933nPp3OALCqpw== 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, Oct 18, 2024 at 03:42:13PM +0200, Michal Hocko wrote: > 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. Yes, I agree it would be good to outline this in the changelog. The argument being that memory.stat breaks down the consumers that are charged to memory.current. hugetlb is (can be) charged, but is not broken out. This is a significant gap in the memcg stats picture. > Also the above doesn't really explain why those who care cannot > really enabled hugetlb controller to gain the consumption > information. Well, I have explained why we don't need it at least. Enabling almost a thousand lines of basically abandoned code, compared to the few lines in this patch, doesn't strike me as reasonable. That said, I don't think the hugetlb controller is relevant. With hugetlb being part of memory.current (for arguments that are already settled), it needs to be itemized in memory.stat. It's a gap in the memory controller in any case. > Also what happens if CGRP_ROOT_MEMORY_HUGETLB_ACCOUNTING is disabled. > Should we report potentially misleading data? Good point. The stat item tracking should follow the same rules as charging, such that memory.current and memory.stat are always in sync. A stat helper that mirrors the mem_cgroup_hugetlb_try_charge() checks would make sense to me. E.g. lruvec_stat_mod_hugetlb_folio().