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 1567BE743D5 for ; Fri, 29 Sep 2023 01:07:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 841638D00E0; Thu, 28 Sep 2023 21:07:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CABE8D0002; Thu, 28 Sep 2023 21:07:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6444D8D00E0; Thu, 28 Sep 2023 21:07:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4DC5B8D0002 for ; Thu, 28 Sep 2023 21:07:50 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2538FA103F for ; Fri, 29 Sep 2023 01:07:50 +0000 (UTC) X-FDA: 81287847900.02.DF483B9 Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by imf23.hostedemail.com (Postfix) with ESMTP id 64DD514000D for ; Fri, 29 Sep 2023 01:07:48 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NRVHEAv1; spf=pass (imf23.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.46 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=1695949668; 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=5g8ip1Hfb6Fb3NLvr5JJcqhAnvl2wXLCCuGQvM5dTy0=; b=UdcJC5Vqi9ZoWHBE0MHWuAi5bSYDCEIHfA0R6SPhTSGWtqIQMWpLNiminEOQJ3I3vRdlFR MFYioxzP0gCx+hpY+rD9rQVnonVwLKNdDBA+p29AjcubyhycAndR1BaCZ8bLkK6Of6iZZP taxZq5wWIGlXbrqptZbaTJchlspetUw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695949668; a=rsa-sha256; cv=none; b=7ju0zkuAkSe69kJlhIj1OqBchysULwAViC9S3V1IcNiN0FMLEHfu9AtWAg+s5qOApGHQCv MZs0luQ1N9JArtn8xasDNydmw1y+rw0u5bGvx9R6Fo0x+xXDAzma7xp2mxoNDbNXXLi45i UVc0Gm/c8fXAi1pnuX/Cr6uknNbxhWo= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NRVHEAv1; spf=pass (imf23.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-79f95cd15dfso440625739f.0 for ; Thu, 28 Sep 2023 18:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695949667; x=1696554467; 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=5g8ip1Hfb6Fb3NLvr5JJcqhAnvl2wXLCCuGQvM5dTy0=; b=NRVHEAv1jLCiEMh4IOw9/Yp8p9tThcQabZzc/m+GR9FLHDbdbiJcSLZFxkaBaKhxbl zVpBOpLv39GrC0mD7dbC72GBsFI5npDqkk3xuQXeACxVgMQ+DXjOHtbrjU5MrDyzJdZ7 Xh53WxQuHylKDHpC3ugnLNQamyUqDRCNZif/X5V3P5PVOK0Os1iaroTpZTwSMI3pGD62 XJwGJ+VqCveHjONQBJC5lfYPj0dSqqrrY1vSulM2yuyZrJmf/rveHtrjghPa05BBFbY0 RBPo9hJjpXM35sJ6JsCrAtLEiuzhxt3RYM3B+xI4cfJio0roPmkeCoP/g5xmgadMb8/Y akEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695949667; x=1696554467; 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=5g8ip1Hfb6Fb3NLvr5JJcqhAnvl2wXLCCuGQvM5dTy0=; b=V9sPLYi9Cu2WclPaUWCHRrnV/K+yd9y+NqagU5jG/PB76vF+UzjGDiBO17G6eXmHZ/ ctrelMqWJLk9HZvspJ1/zU7nGfdKqw1aE1PHi71p9+Mq9Iq8QKnmjbX0Zua5l9nZ4IUI 4nG/mF7kRnUyqwiqcinbDzhqeav/bAzGygaByaz8cTUzNBLWuaYaVAShmODIvJYJDxc7 fbWjodyoeAuxtbDbHehtIMORNNGD9o5bp06zP35bJB6K0vOcG/OxLZMtgUV8V2jkoqiH gLoV/7KXPyYDocKzxu1VHBQN8g0mrWWMx/Aq4lFY9AyGT/cti3rxFbzz3Y99zSW1a+Uf 2pgg== X-Gm-Message-State: AOJu0YxAFxwwBurLwHdi+r8BXqHasfkUNF91VYWG6bFb6UcPkUBmFIFx V8USdWNTpCw2lKD66C9RcU7Zu8PJcgj/oJqjdz8= X-Google-Smtp-Source: AGHT+IHYOmQNQlpi393slH78HhN8EcL32BTVoQx5UJoNgS5sGhvztAxAWvp0lJmcD6QIUys0mqxI9uIuwt18ROhhlXM= X-Received: by 2002:a6b:fd01:0:b0:792:6cb2:e92c with SMTP id c1-20020a6bfd01000000b007926cb2e92cmr3013736ioi.3.1695949667512; Thu, 28 Sep 2023 18:07:47 -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 18:07:36 -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-Stat-Signature: shks3x3457ku34bydq79wycpaua86yp8 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 64DD514000D X-Rspam-User: X-HE-Tag: 1695949668-664245 X-HE-Meta: U2FsdGVkX19X5K3dD9ZEj863IikIoZd/9vdjcYpEM4My9r7snhj/IuPpdKaTq/2Y/EUE6rX6mtBkr7oX3DC2/8Y3whxWXISUaJf9yJkd9VKl6sFqLpscSZz/eX25PSgm4e3lyZRiFW1ZnkWaUIgInJv/8pntQVRSjJ0B9W1X3rMKd54dN4pLNw1qCrHCZdS3wDF0Tr3N4g/oG6BC9ApjyqpbS8Nbu/uiAD8MsdeViehfeg1raqfI6/nkYLd3aAJbhNIsdoRpS/+aokS6Cg0OGWCslo2YpEqhma1nRxN05JNj01SbU3UuRigd+6G2YJZxUlSHOPuziP3ZGSki2ijVU1qjii/b5sJtDj/B9CaAOtilP9A0FGYBC2MAP0s8svlo0Ew/Ac5REF+2RHfra1IcbgBMNB5Vo6fsXicNdcwCJL59ocbqtL1DxrYS+9zT6ad7l6GmfnjlqgtN3mFK0sStdz2e38N06TMeTM3rJHm7G/7343q7vGyVYnpR1BOxU+ayz54CZ1C2CGLwvOXhgJ1yGlTgzlcbmsGXdVUY2NYsUURx4i/gw3JUOv6Tfi+0/hC9/HD1yZCks3ub8u3ApE0i/Q/figh9AHox5JsEZkWfbvT+N0lVum2E2I+RVcFCL2pgkmsb3oj0n3vNfZW4VOoZfo6+MTlbvjlcN8Uz6A8JjMM7nlE8Ge5cTwHbNCNS4sbaHEwNlmjQ/PNeHup0PW8siap0OFlYtqjTQDRStS9MvWNjQZc5551dWaucMclYAIAhw96yhMI9ZixppXT76pam0uFBFgdoUpJ2xFCTNd3S4m0Bx5hygRREciHfWG3/HajlRNrmg8eNxi3WTEZ3vLtuRJ0pb9zudU6iSY8ZqX8pPMM0DPZGwwoVe/S6P/zgknNSjLY6kqUmdUSQ0hDFd+dr2qF217xEQBIyymWoUSkZUe6iTLlPHSXhThKMJ7DjQ8SeO+4nNaYW2aLkYg7LIUO B+Ph6D1H ao1y7yYHK8NLdNLxc3ZDXC4mn1xR9S2rtgghkA3Uoo3Ob0DqFpHW5G1a1mwpXYBOWTOriFHktE9xnA5dpfpd6lqXm8suBThfy4Jm+OL4mubgPhyeedJzu6Kw6h2+PMct8VZfHCYpIPASOo4mGhAYhq5E/TTA00j5UBEA4xDY1QbMa8AW6FRbBoS1y7aQsvl7IdxQInGgk3lhgtJdIc05876T/Zs5JelIcDM3DoSE6BWxf0l0/ci7Reer9GwMvHMKVVpgNAP7UD9QRbSJwbRYFH9pVt/TXgkqVQ2RUqV2Hb2o2YM5gnf6U5R7xD5XSfxJIO0saHtUFBSZUbZUZnHDjg6UkbwxWLD8rVlQ8J7p1slYI5IpjVNsY6qXCdk3dc1iMYTNiYR3/BG65iqs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.038002, 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:58=E2=80=AFPM Nhat Pham wrote= : > > On Thu, Sep 28, 2023 at 5:38=E2=80=AFPM Yosry Ahmed wrote: > > > > > > > > > > > > + > > > +/** > > > + * mem_cgroup_hugetlb_charge_folio - Charge a newly allocated hugetl= b 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_ACCO= UNTING)) > > > > 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 :) > > > > > > > > > + 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 f= or swapin. > > > * @folio: folio to charge. > > > -- > > > 2.34.1