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 0D90CD65C6C for ; Thu, 14 Nov 2024 10:33:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 577396B007B; Thu, 14 Nov 2024 05:33:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 527866B0082; Thu, 14 Nov 2024 05:33:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C8D76B0083; Thu, 14 Nov 2024 05:33:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1985F6B007B for ; Thu, 14 Nov 2024 05:33:51 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B4D6FACE3D for ; Thu, 14 Nov 2024 10:33:50 +0000 (UTC) X-FDA: 82784338980.04.D1ADF6D Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf18.hostedemail.com (Postfix) with ESMTP id 1DBF01C00AA for ; Thu, 14 Nov 2024 10:33:28 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ZYYSbHuQ; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731580340; 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=VBPApLFtlaOK3f4z4ZSIcdYWTPe1i7pEMSXlEit2OcA=; b=79fO50I3F4/6gCh6CI7PyEmvPPVnjzYWfCR2+TwswbDjx2BCB+hXM2bzdURYQoFyilraI/ eax3tQyRoWvHwJIoQaE0HjCML5HPIhlzK/aEXQuxp4H9oXm1QMu2kDwANkueHMSEX8vgQ7 NMwgWAgBX/Z/Ilq4sY8gG2VXTcFbp74= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ZYYSbHuQ; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731580340; a=rsa-sha256; cv=none; b=k5r6kPwB/V4amLPE0yWwv691w/3UKxM0kE69gy/eCcy3IANc6SlUnkvIil+qJeSQNJjxBa bm9zR3qYN8cYxHtj71SsxPf2K+KNBU9RW/Jop05eezUxUBhp83Qa8/T1ET9Y6L53AibTYY iQ8SD0R7/jMmbexaF30MudLD16pie3c= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5c95a962c2bso720739a12.2 for ; Thu, 14 Nov 2024 02:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1731580427; x=1732185227; 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=VBPApLFtlaOK3f4z4ZSIcdYWTPe1i7pEMSXlEit2OcA=; b=ZYYSbHuQJBQXBvxFoJwh+v7haW8fZEIpoBE1nU+RSh+Z7qHd5pvcP5hiKFINcw+HKC I5pAPXA/9MyDTvLYJfSvfErAgcos17RR2VmFTBNxatMTd3SE8je6n8hCOUpu4XTgf3JH H/RTwpjB9Nh10vX15YJJ9heZpKAm1gHYCg8rbqm+R01MGSZfdRaesTTrjYrT1QNawnNy FW+GJxUsSJdg++/gqACH2Ct1IQ61kY83Hvb/CNcQ4hV4zlaVwZDz6MK7JBi/VXe6/DuQ LCJBe2JwwA2LCLW44m1GfrZ4wOmml20Ujyywt0saD1khH3++1Ehl7G0Jfa576MMygb99 czyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731580427; x=1732185227; 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=VBPApLFtlaOK3f4z4ZSIcdYWTPe1i7pEMSXlEit2OcA=; b=DfH3VtUQyo5dUcgaY+eh+KoONypkDq9n4ExYAiC2d/FCUipySWISuHcgUMXjC8q92D sRE01nlhGB4csZPtKnhDZU/7Or5e+jU8q3RAY0QjtQ/v5LQ1jKuStGdThMPUJSjWvWjz Vtg40MISjL//MoJ1Shyudi6t6EhvIqVnCJjONTApCsx0lEjRMwBTJ++jGYppP58nwKJN lyiGYSkvYkhFX5ET1k//ol+SnA4CntGgb7RJVj992df0/EVsKX8tciR0tFWtXmXnCTkN MNEXcvPU59hQ4ifm+KsUv+lHtP+cueSdlP+ZaCrxARU0vP5foBdwYG3peoNn8ARYvPLG YW/w== X-Forwarded-Encrypted: i=1; AJvYcCV3sTosBiy3YbLIM3RUZf6uKSOa2aT3Ux+bFXIMo7igx4OZLGNtqQ1cr4X/E36jatQ6rra0C8fhnQ==@kvack.org X-Gm-Message-State: AOJu0Yz+Y0OhAASQ3xtrizRUdIbYssgkhSljjkwP9oC6bOMl33qptvJM U9xjjVh3TDMJ+xmfIk6JeZAx4KnaBSl1umgEU0np8unkY6jb1BS7wcSUJWfJRoo= X-Google-Smtp-Source: AGHT+IEmLsdovsIKeaEEvZwYSPZlHx1HJdNmxwuq2BlsvFnUk5lcIWWhA0cQDnKQAWDSm08XlzLyuw== X-Received: by 2002:a17:906:c150:b0:a9a:f0e:cd4 with SMTP id a640c23a62f3a-aa1f813b746mr585216666b.55.1731580426995; Thu, 14 Nov 2024 02:33:46 -0800 (PST) Received: from localhost (109-81-88-120.rct.o2.cz. [109.81.88.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa20df1b642sm47126766b.40.2024.11.14.02.33.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Nov 2024 02:33:46 -0800 (PST) Date: Thu, 14 Nov 2024 11:33:45 +0100 From: Michal Hocko To: Johannes Weiner Cc: David Rientjes , 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 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 Content-Disposition: inline In-Reply-To: <20241114052624.GD1564047@cmpxchg.org> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1DBF01C00AA X-Stat-Signature: gemsch8yuxw519iwgt66yut4bw9yycks X-HE-Tag: 1731580408-484449 X-HE-Meta: U2FsdGVkX19+TpapNMKBGc20aMkbahs1l+y0HzYQUr3aUZSGtL9vHjzOllXyZmuEMlH8xalF4fAqBa867/0mJKJLj0vt2VeV8ga2wcjOwBP8yOELAbaN9HEAQk87dHDsfZZsdPV1RKnlilA6tVW2u3/JcjxbwdrGPXReZNoQajkdXKAuTLXe4D3cKdATnZbzfnOQvluzV3pIyzUg/4fpDJlf8DUc+9Hxd/cJxUBjCJjrpCQ1kv6KvWQ09AwBYSNKa9s230dVcfl8fQtX1O8/56mRBBAnoiE0zDdzjAj3DDrQiYNy9AQpC/mqZf4XZC3O3wCEwhqeC0CWeh1VIrUD1OY7uIAylhvgoIqZFUwI9OirShPpcV+2QI91pNB1oMEwKVU8+JVO1oSYwuMWIkDPSx34jGH29C2X+/nu4yr76qqNLBELzfpCo/ZfpzqMcf9txU15djXANr51BbXD0koZtGPlQdhsrcKZkWQmUMsBHEirci2xtpS98LJujWim846gLJ9jn0pUI62aKwtNCqFn7Wi/hDcGZGNlIsfExBQXnr/gh0ruxnJdsbZSARgpCruJnaYr0uJDghuI3Tx6cj4u8QYw1loqG+WTJG9sys3kuocnk0kvzXJIo2xlb6V7q+cTfbuPspC+LEQEyAoqGlvvQYj0rtb6uoAqFJgyhgUgCHKdu1KPfzkDJOLEvZP9S3XZaO7VoY0PvyqMMpNC9TxHZiPWAPLM5+eSZsoZL+jDdu7ExyarVOs4CjQdb5kjqTSqUKzdOOKpignAmQ4EvpFgvicxIlFdyy3u2uF0m3n4I1tfGWgvfEOdHBgcKF5+AGB74bGE+Pog6y/l3L0S5vpXIlYNZ94qSu7uo8N454MAtpwpnJszI48yWCyYTyBFhvicSjJIMC3MX1ivQncEUWKZgiCANiO9dV51d0INQ2+d82kahhi6UHjAYtUen2iIqQtSGbYxKn4yUxtlEJ/IQlX qWgjbhZ0 Q9VNaWvl2Ckor/1YZstleSHWbD+RFSqpM9YDqRACVubitz5okaVG3d9SkPhGiLD7+ndGG7xez92/v9uY12tvhLDI/ZK3G04bfmdV3QBe9+SLSFjCLpIkOPCZn3Oo1Ib6uUjFhTG2CRSG1yBQvgudTmfUzgNahgVvgnYzcCDUkjzmircF0WaNcgn3nRy5s13S9hDXHADP2LQzG89EBBRWYjjUY1HuO3qmBzjTbnJE1GNp6lQgr/IXTPAsG9XhuH5n2VIruWKNVCr3LcrIKlpwBnQQPaLHlTPaXWhkabpCtBlcFhZh9sNWnm/RzP7gjG8KFGAuzqEiDfZprbvMAPp9KBVy4M2sczV5WbMBS4c/1GoucRo0pdSkFGdswLFIix07x5dok 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-11-24 00:26:24, Johannes Weiner wrote: > On Wed, Nov 13, 2024 at 02:42:29PM -0800, David Rientjes wrote: > > On Mon, 11 Nov 2024, David Rientjes 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. Completely agreed. From the memcg POV there is no way to control hugetlb pages or manage per size charging/pools. In a sense this is not much different from slab accounting. We do print overall SLAB accounted memory and do not break down each slab consumer in the stat file. -- Michal Hocko SUSE Labs