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 20B2CE743D5 for ; Fri, 29 Sep 2023 00:58:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0FA38D00DF; Thu, 28 Sep 2023 20:58:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C00B8D0002; Thu, 28 Sep 2023 20:58:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 886FC8D00DF; Thu, 28 Sep 2023 20:58:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 755BF8D0002 for ; Thu, 28 Sep 2023 20:58:54 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3FF74141075 for ; Fri, 29 Sep 2023 00:58:54 +0000 (UTC) X-FDA: 81287825388.05.165CB2F Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by imf25.hostedemail.com (Postfix) with ESMTP id 712CAA0010 for ; Fri, 29 Sep 2023 00:58:52 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="jwFip/jF"; spf=pass (imf25.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695949132; a=rsa-sha256; cv=none; b=SBecI0v/ONnve5f1zJMUVzrZDhPSMuaBL/MlF1JhbYoqYB1IuvU3aLp8ZO+PBeZbBDiHVk fFliD3ns7IERsx3B24MYj/cSIDq/gXUUk2qicktr0cQbvMyy7qOhGQ5bRo3vnr+ey79Gj9 JSzWiGYztp7FOUbubKaSqn3/py07Dbg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="jwFip/jF"; spf=pass (imf25.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695949132; 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=cQhR8ua9u0kwxviXq1bg935rieHu4O72pOc1/rhQSOM=; b=tpS0cNWPRvaTH6xTWpbON743IpVwp72rX1KfsuxBaHXd4bHtJa5spBFLclQBMeNOB8NwUa xQYZUgY0YGKw871r2B3Zs7IVWsJvVZ3G2P1hHIdFwTHXcaLhwnmbW40HhW5hFA+9Hi26SG W6DUZ3pW3eHD/fHq6S33ZfxUjoVZyXU= Received: by mail-io1-f48.google.com with SMTP id ca18e2360f4ac-79fa416b7ffso424525239f.2 for ; Thu, 28 Sep 2023 17:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695949131; x=1696553931; 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=cQhR8ua9u0kwxviXq1bg935rieHu4O72pOc1/rhQSOM=; b=jwFip/jF4RvVSVPCcIZAhQ+eoqMFL8DZ12gyDtw0HCc9BixAcXoIzpnZ8JopGhZDZT Ha82glFvquUCGXgWZqaMA8mmIh5uJpKPzcCiiRKY7yVyLt63eRYCol97kp2jYQ36mQEo widbothM+gbNs3DaQvvTT1nCe55npWFEWFvW9K0vSbIj48Vuf2q4f0eHyVzNi/xbmz3+ bYns1wZeo1OQY6w16s7unB4mf984o3dpteMQ3iO1zAepRZ6OUjSoG8+/jdh122QIbGRW VmJwjuVTDs5sfUgYL2SsooVEPl3BbWc8kTDDLKxEer01GDxS6oiO/k64fmDLM+AopZVB NJdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695949131; x=1696553931; 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=cQhR8ua9u0kwxviXq1bg935rieHu4O72pOc1/rhQSOM=; b=fh3rOjJOYwpUMssdD4x/uOdGhdgiyjZFrlIp86M7WtGLfi1cWG9OIWihtMB/a5afgF bCxcR7wbzSDl8rGUBMcDgUdaxE/EqivNsQtC0BYO2YZ4cB2zitKJGSDWVk8BIfC3Cy5f WV4IWdLd4cKuHDR6xTSuBCrmNb61fA1dXguv/I5t3rWb47JzVtNw0BYHzh2FRKSW44+u 70e+ZYw03aXRlSWCdTVkshVm6vyVHAkk072VGxjTvyWqE+YciJBvTSkkHltRgjGgCfG8 Aypt1TkSR+OVmI0JsIIFJpDwGsNWNOT1hPlrDEcrkW6mjqdmg94DrDjonGhf7FZ55qMO 1nFw== X-Gm-Message-State: AOJu0Yxbre00rIVS5aimot8+zmJlObe5auISfySZOy5yIYrX91oGU5jF vxTxCh35tJtOnH4/5y/Tnyt9PYx7Wrguc1sYtDM= X-Google-Smtp-Source: AGHT+IHinTu386Q3JuFdZBoiwhCEpmnImaJNx1XG73Tt/N3OsVKpe0IeK9BKL3QLHC01R3kxGnIrCCrbnJwW8a26J6Q= X-Received: by 2002:a5e:dc44:0:b0:78b:d0a9:34fb with SMTP id s4-20020a5edc44000000b0078bd0a934fbmr2937625iop.20.1695949131499; Thu, 28 Sep 2023 17:58:51 -0700 (PDT) MIME-Version: 1.0 References: <20230928005723.1709119-1-nphamcs@gmail.com> <20230928005723.1709119-2-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Thu, 28 Sep 2023 17:58:40 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller To: Yosry Ahmed 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-Server: rspam08 X-Rspamd-Queue-Id: 712CAA0010 X-Stat-Signature: ijuepex899rixwaj6n777wg83ab86eox X-Rspam-User: X-HE-Tag: 1695949132-158442 X-HE-Meta: U2FsdGVkX1+yNylrLQvHFwwEW9fjSXNnFeirdJdgyBj2iMUWG2SEIStoDD8vLE8jTBx+xEMpcv8OXvqnp8Jx3zkzyB6fL+m1WtfP3hN8WvteqAuM8kHIN7RfqvjBGRwdF2Mj2q0boARt3Cev/vOHHvrGAySevcCJtM+diEj7WqMPy2FSBUClwqkuhYb7HvIlI+VTS2aAw7SJq/Q+Mpxc3AuZY4saY5JAeUTdJLb1rVhPcFYRGoShNUAbyekBn41mH0zO1sgLFwXmEeKLi6B5ssZRi2r4Mgx8G3dtbC+WsONiHu47hzotOvIOpa8/ZJmjkZCvs7fg8Ycd+33ndJeMKL75uEQ9iEWLHtOFmq0Ei1cFNnEoiON2ZNeP2z3sa79kz9q0JebvZ47/MtDkPk1rxwDtZW28P9wWDt0gqI6lOyoQf5FYyYZ37BwwxFCHdMXR7XPVTIppdo0PSQENDNuRZ8sCEm+h5Ovf012GNLH8e7s+lMNfBf9im5ULipD64RpqKpREGkiRcl/lpLP4XA+sdIi243vZXiyOhZkiMmtqzeIcLMLSlKsxsPXfesjZliZ2Cf5nbcNZhKqdGrSAira3tAczLrwWld6WrcBaqF78xo0H1Yqkzag0QgmGskD7RAz8RbdKPuRFJXbrndN7EtD4maow7GjVFHADiPYqAZdN8sPuSRzw7ryG+vdGxVkxi9Ispxpi4o5/2DGfUsbeSN67YaeIpoWhAlQz3mLDTtObs5O1BE9q5jHoLF0do06oBiUbaHP0H4SxbV6XzaMRTM5ok54PWm952eBYFoRLuwxTvjwo72iPo66GcsPgjkLpK+veWe4+klofjeIxFn/cGsvSm8oRTE+Xr3uTE6xhxLzA6hxkh05TCvGVa8TqnvFrC85lzRRL2d/7ZVmLR2Jx6YF+1xLPVCQs4UHypqxcTYozMH79KgAgr7PJ6py3zHvq8qTChRy336vFH4fOuPJ7Y31 NpYN9EC8 9t4bpq9RZhnhpxAkUuXFvG5JvKYCtv/WJCgfKMWekl8lGK7WoAAgc1Yx09o7yheLmnkOhdV4Mw1IplIFAP/2iBhhsksjhAUO24J5/nRgoelEvybt6nzYx2KGMuCTj7vTmmOp4+taObyTlqCDRmBQrdtjm/RytZ1oUEUMCCZV/XufS7dXBjrsv6/fxLS9T53vjEXLW5DAqx/JPVao71rgJocsd18BE73d040OQOQV6nZAQBpCzfw/r8OWuKTgzBPr4ag6nhFZ+yr2gyex31NyBP+RMFyTkF3ENteXH/12B3I6JQbb8932Jyw1nhh+jWRE4ATNf0ReoosXLQzH8R9CDTdd1emDX+HdHtrjknrXeqqyCfoC7ZG1QygQl/g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000147, 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 5:38=E2=80=AFPM Yosry Ahmed = wrote: > > > > > > > + > > +/** > > + * mem_cgroup_hugetlb_charge_folio - Charge a newly allocated hugetlb = folio. > > + * @folio: folio to charge. > > + * @gfp: reclaim mode > > + * > > + * This function charges an allocated hugetlbf folio to the memcg of t= he > > + * 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_ACCOUN= TING)) > > 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. 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 :) > > > > > + return 0; > > + > > + memcg =3D get_mem_cgroup_from_current(); > > + ret =3D charge_memcg(folio, memcg, gfp); > > + mem_cgroup_put(memcg); > > + > > + return ret; > > +} > > + > > /** > > * mem_cgroup_swapin_charge_folio - Charge a newly allocated folio for= swapin. > > * @folio: folio to charge. > > -- > > 2.34.1