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 21D30E743DA for ; Fri, 29 Sep 2023 01:19:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 985238D00E1; Thu, 28 Sep 2023 21:19:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 933738D0002; Thu, 28 Sep 2023 21:19:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FB338D00E1; Thu, 28 Sep 2023 21:19:02 -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 711D38D0002 for ; Thu, 28 Sep 2023 21:19:02 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 409411CA191 for ; Fri, 29 Sep 2023 01:19:02 +0000 (UTC) X-FDA: 81287876124.25.FBECAFB Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf24.hostedemail.com (Postfix) with ESMTP id 7472D180002 for ; Fri, 29 Sep 2023 01:19:00 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=j6z0eRa3; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695950340; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZndDvjVADU6GuKHszhELnx+eP/DDe/5FgQazo+VWICo=; b=eJtfOkBc2rG+kWQgZsiO1KbabIFFGMH0JAOWuMfxUkpHmrkb3nAFTrVnDZnEXJFaPVZyhU pRz7fyPX/EqxUvFod1fYpPGb64iPynvg8v1F0CLveERQXx2QDDouF2TSsGYm2QmiThICXK imikd7LfaSs1dBxT9YrlJeqfd/mThaI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=j6z0eRa3; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695950340; a=rsa-sha256; cv=none; b=wjZpDiQAm1kzjOaVtBaLbzYtoqd/NUdNj6dBy31ln3YIDTwsRwC4lMC0+rJVZFQz0OO1bb Nnjp4x8bh++GTSYeeCauSHUYOFdtypCHnaVr2YRyJO2G86aZjAF2xJWSk/SBLUc1iUAWzQ jYS+npM9OPj08m+sqE2Azcy5qDyIlig= Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-9936b3d0286so1801140966b.0 for ; Thu, 28 Sep 2023 18:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695950339; x=1696555139; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZndDvjVADU6GuKHszhELnx+eP/DDe/5FgQazo+VWICo=; b=j6z0eRa3uBvhkl+yoKV4NCip8SNk6E7GHpwlZy5fpr0SZ57+eLCQfbnK6KEogjdicI k4manVoSEQgEtIRFCNFJ+5m6M2nErSyIaP0y1COL4UFvI73RRsC4R13YAKEUX8Qh9RtD z1LCl7Y9VH/yLgQ0VoLK75uuezWQ/XAC0s/XiqhnHVxsfZ1G/7LntDpoK9jmXOOl5R4b MrQWMlKGSVwKrSwDeAETbkxqVEaLjgA0OM4LBE4bEZDPkDSiU6LJNeQ5NjXOmEDL0Hqf p4LZFIVBuQiTdrkdnmepGTHh4QDK7V/MmxuLTaoJcMz/ru92uOgZrJmMcWHTnmULMnny esSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695950339; x=1696555139; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZndDvjVADU6GuKHszhELnx+eP/DDe/5FgQazo+VWICo=; b=WdmdNO4Z6aHOYWO9DVC82sYJqiVD97PcJlHGaaM8D3GzdP2vrisMTqfgqT8ZMFtbOS pRjlqbSzND9Wa+EICvFv83IRt09ECkCF7AtsBJpfAfKjLlD+tG/I4jxAZBzdUaO6YbyL OxqKi27sMDv3HZ0s4D4j78K0Oub4/MUjx1QjlTpUVIiBGR20I+1WpmePDTzRtOkfTCnt Y1wsxuj/lLWZcKLdY4zkWjSYZDfAVP2z5DNnUXMSJ7RcY3ZTtp+QjEi6bqNpD3HUUAtR yMcAuATlrlmkIXnGedUacAxSN0GpLmC7x8Q/Y78oLkUxsnWiG81HtIhhfFSpxTCKRayS 9nUg== X-Gm-Message-State: AOJu0YwoCXHNH3v3appyV1tgIUDCFsB+2nCZiwSO3RYsmpXkmsvZ2wlS tqIOzwpEieNwp7qxpYdNuNJXSZ9LH8+iBdgE3/yQHA== X-Google-Smtp-Source: AGHT+IFoqMyTpIfX6uaS77LPHDhJX8I+COqi1KAm9KTwagfqUaqSfprAUHibwy8HOVZyyMoMo2FVR53POoJHHT6q4hc= X-Received: by 2002:a17:906:209e:b0:9ae:829e:d930 with SMTP id 30-20020a170906209e00b009ae829ed930mr2742309ejq.9.1695950338777; Thu, 28 Sep 2023 18:18:58 -0700 (PDT) MIME-Version: 1.0 References: <20230928005723.1709119-1-nphamcs@gmail.com> <20230928005723.1709119-2-nphamcs@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 28 Sep 2023 18:18:19 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller To: Nhat Pham Cc: akpm@linux-foundation.org, riel@surriel.com, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, tj@kernel.org, lizefan.x@bytedance.com, shuah@kernel.org, mike.kravetz@oracle.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7472D180002 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: aewohz3gd5i3bjbi6n5mrm83mqzpaxms X-HE-Tag: 1695950340-281948 X-HE-Meta: U2FsdGVkX1+6NbvdIUtdEDR1tLs+whSBvdSHCEQwy2vuRiWJaMqW48bLUphwqz1DLlU48htvQvJJH6N7xctOR3XyBQAqMLYNZoauwNjXstayyUMSfp3g03FkZ7NM7e7yYM44HFeOJaYJDCcOLaTaS0fd0Va1x+161bEnSDd/Tyoi+Ck/ezfNMg2HWK7jQM9dgxl9ZwitRCcydsVMdL0Jzubdcp0ftx3ucEtlnhToMiTlCY0rndChZUjgKz7zpuGqZnn3+moTx4n6/VEPlP7Ugj0o5Qo0Vlhiyu5whU1OPoY8vzrX7hUMdv+8NDxJM0pNFjO4uo2G48loUPF2OaKuRLF1cYuLGinftfc/j5pEQLLL+bx4cxN169a/wdaUOGhOs3cAk2kaayGpxpSQHTwAnkLebiiIAAzeaW2lJLWuN99ZfQCun5ibtzLF6tOOx55QIRvGZ1IEA+Iuy0FWgfU60JlMXvTDWwqAp1pAfY+Cf75rSXyMvQBnRg5FV0oPcjN64gKIU5K+CQFWo4CkVriw+6Dgkrvti3gMjoGw7kYLdSHgIS5WRSb5NiLA85gj8sS45kft20dH/Y1G22XHSDzZpQL+kxmvbjskKlQ07r/LfVuFS/h6XiyACVT8Qtl5dwMZnxTdkOUYxW0ULbekPYUqH7wwn/pqQozXe2IWi80Ixz+C+OY6X1mx0SoNfJtaSmToq5nn+A6xKC5zlurgP8ON6c8nLzBCw5wPScOosGb5bEv9wbz6se6NqKGnoCxqe1V6yhIBxHH2dNEOMe+AuG6DYhtgkqIlE9MJuOBGKlxv0FRkHl6hoyrJjtKk+nxU5KXMUqxj0VJTFPgAyyJznZZhQCeN9XXrWQiwGufow+Z18CVS58+k/pjlGFN/9tW1ukXM128LiG7nlQg1DLDEdWBagoAdMY9ivVCaTBsiYC07Qjn8vmV/4XVFuEHQ6wmZS4d0pVH1kHNA/Fkbs5OYBML XfcRRBLf H64uIFK0ukZpJeCTeGIgr/6/sAs6GIdDniJbyQ5OtiVhSGqdTPZhokAwvqytKeQUi7FyZwAoXAkkH4ky0N0MRTznPkvrvF5G38SFF+OGcVMdk4hT8bzfbuBGLrPCROu18Ln9I3PrtoyZ+QB+/BJujOxATL07Yki7f2KtafZ+dzQc/N4+rgxBCFEAo/QSe5Pofz5F1sgsPVRLLmi4SZi1W0YwKrn9uTan4nykYc5pcUejfT9R456hANwEmrMogIJxG0Vx5PZd91MZjOaxvt/18EFbpmg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000461, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Sep 28, 2023 at 6:07=E2=80=AFPM Nhat Pham wrote= : > > On Thu, Sep 28, 2023 at 5:58=E2=80=AFPM Nhat Pham wro= te: > > > > On Thu, Sep 28, 2023 at 5:38=E2=80=AFPM Yosry Ahmed wrote: > > > > > > > > > > > > > > > > > + > > > > +/** > > > > + * mem_cgroup_hugetlb_charge_folio - Charge a newly allocated huge= tlb folio. > > > > + * @folio: folio to charge. > > > > + * @gfp: reclaim mode > > > > + * > > > > + * This function charges an allocated hugetlbf folio to the memcg = of the > > > > + * current task. > > > > + * > > > > + * Returns 0 on success. Otherwise, an error code is returned. > > > > + */ > > > > +int mem_cgroup_hugetlb_charge_folio(struct folio *folio, gfp_t gfp= ) > > > > +{ > > > > + struct mem_cgroup *memcg; > > > > + int ret; > > > > + > > > > + if (mem_cgroup_disabled() || > > > > + !(cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_HUGETLB_AC= COUNTING)) > > > > > > What happens if the memory controller is mounted in a cgroup v1 > > > hierarchy? It appears to me that we *will* go through with hugetlb > > > charging in this case? > > > > Ah right, cgroup v1. Does it not work with mount flag guarding? > > What's the behavior of cgroup v1 when it comes to memory > > recursive protection for e.g (which this mount flag is based on)? > > > > If it doesn't work, we'll have to add a separate knob for v1 - > > no biggies. > > But to be clear, my intention is that we're not adding this > feature to v1 (which, to my understanding, has been > deprecated). > > If it's added by virtue of it sharing infrastructure with v2, > then it's fine, but only if the mount option still works to > guard against unintentional enablement (if not we'll > also short-circuit v1, or add knobs if ppl really want > it in v1 as well). > > If it's not added at all, then I don't have any complaints :) > > > > > Other than this concern, I don't have anything against cgroup v1 > > having this feature per se - everything should still work. But let > > I know if it can break cgroupv1 accounting otherwise :) > > My concern is the scenario where the memory controller is mounted in cgroup v1, and cgroup v2 is mounted with memory_hugetlb_accounting. In this case it seems like the current code will only check whether memory_hugetlb_accounting was set on cgroup v2 or not, disregarding the fact that cgroup v1 did not enable hugetlb accounting. I obviously prefer that any features are also added to cgroup v1, because we still didn't make it to cgroup v2, especially when the infrastructure is shared. On the other hand, I am pretty sure the maintainers will not like what I am saying :)