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 8F7D9E71D4A for ; Fri, 29 Sep 2023 15:12:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A5048D00D8; Fri, 29 Sep 2023 11:12:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 054138D0023; Fri, 29 Sep 2023 11:12:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5DCC8D00D8; Fri, 29 Sep 2023 11:12:37 -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 D3E1E8D0023 for ; Fri, 29 Sep 2023 11:12:37 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A47DD804FF for ; Fri, 29 Sep 2023 15:12:37 +0000 (UTC) X-FDA: 81289976754.28.333D6F8 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf06.hostedemail.com (Postfix) with ESMTP id CE98A180004 for ; Fri, 29 Sep 2023 15:12:35 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="c/tZER1c"; spf=pass (imf06.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696000355; 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=+iwwlqvaBxCwMsikVRLEIWQ+fldLakckoypjf/711hA=; b=q24ajQqFFjkMJOXrNbfNP2V38O2WN/QE7U9U//qrcNcrokUdCnpxQYeuPLnJivySnJmW2g Q7JL5X4c7f1Baj//Gp7RISnKONt9jQYBkhPgt0GiuOG7jb3JFa49g+ubiAjDGxdm5+8fg5 LOquNaCEq5KjtUEW1l1fP5cjxOfqKP4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696000355; a=rsa-sha256; cv=none; b=5UgNHMiiRoVwVRUGIaUBv4b4Zci+NS2/O2Eru6I5IQ3tj++/kwSfvy1URlz3TIinFQJUKj 40tAhJMbPg8eE3I8p2rMXwsSuKKjGGcTrDdvc/wIlyjOfcxTPrHOWRwxtGIMElMKbcwy1b ahQU7Rz/2q3DUuzKTlc7fTgZg0tJxII= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="c/tZER1c"; spf=pass (imf06.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-9a9f139cd94so1820928066b.2 for ; Fri, 29 Sep 2023 08:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696000354; x=1696605154; 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=+iwwlqvaBxCwMsikVRLEIWQ+fldLakckoypjf/711hA=; b=c/tZER1cHNXyoVmKufjsAtVcvbOTaQtGD/3mvBiz50GZVV/q6cQQzuNSzPeih+TQZB JdyaeZ9ignVywHOryW2qXp/GMj/csYWxUQDjHfpFRcgh3LkRDFDUYQTMEudpHu8SJCoA VLnX0SGfLKZea4O5QDkOXcVOpGaWKP+MsGbIbgloKdxp9tuxOE95IYsB16/dodQS8gwV COp5n7qEF4kPfYtgQl+PlgrRuaBBoQXmzFEJstl707wr4PGK3k63w/x/FZDQiCz/YRvC kj8I7mFrxrsruRycL2t6lwNGbEbCCuXTLHM7iLe+rp2225460LZiDtMlOFBvGFuiQtNF k9vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696000354; x=1696605154; 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=+iwwlqvaBxCwMsikVRLEIWQ+fldLakckoypjf/711hA=; b=hSE/MvIegTcYhQG8nOmBzY4SVARUBD1Kf4QjcDoCfREF0Zw99sn0g90uY+r8Nufnl+ yCR2oiXG+sXGPpJjYVxSj7gTXFfOOkVsCf8Acqkfmfh3xSMH5dK9VT4yBAmfGR9l08Pn ICjnJjy/fghIvFHKIxepAm/k48DvVRqSn5mPjfkoWkM+LJmnXSYWJ/9oGrKAtiLD2n/T svvb94fTZo0K1hdMotVd+bk48mb4bHoCx2J4FlLYFZpRL+TVrKpfPonbm9R8mSbGy2bd IWQPKKKfnUYCTmL3fSZB0gJzl3gUxS+PgZPuhJ+D9U62+NRzpEUyap4LdEuZr/X3T3rR acYA== X-Gm-Message-State: AOJu0YyWmiMmG1a5M/1srEcVZ7mQoD0IjhI2ZCmSarBtv8Dk6W/auZlo SwtgkbAsUs/OUKvSCwEMU7oFFP2HG1SFwQodlED6Cw== X-Google-Smtp-Source: AGHT+IE9nhh5YAWBRdZlHuUBiW239B7WmIyskiK8JhYc35cNDZz3QR5wJYtEmks78PHXuV04TR5vMLHpPqOHtRE6jKo= X-Received: by 2002:a17:906:51db:b0:9b2:abda:2543 with SMTP id v27-20020a17090651db00b009b2abda2543mr4673191ejk.65.1696000354025; Fri, 29 Sep 2023 08:12:34 -0700 (PDT) MIME-Version: 1.0 References: <20230928005723.1709119-1-nphamcs@gmail.com> <20230928005723.1709119-2-nphamcs@gmail.com> <20230929150829.GA16353@cmpxchg.org> In-Reply-To: <20230929150829.GA16353@cmpxchg.org> From: Yosry Ahmed Date: Fri, 29 Sep 2023 08:11:54 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller To: Johannes Weiner Cc: Nhat Pham , akpm@linux-foundation.org, riel@surriel.com, 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: p39ghh5ywgucx8ehnjd4g8gxo8ur98to X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: CE98A180004 X-Rspam-User: X-HE-Tag: 1696000355-142807 X-HE-Meta: U2FsdGVkX1/rYlpBI8X9b6cio+1WaOkxCiguVnYnIm51kzGqO8h/aZY7vFlOK9TkCdIpsaWII7/uE5HVoARauc3lyMhGzijTNn36D3TyhdcfkrQzv/j5n1zI0/Qlizgi6+jESqP1Mjcp0wePp4SkzdxBm9h+SZfpnBe1ILUFMeO35uM4sgebNiatreudy6OX7yqwVmTOPRQUmGd/HJiGZabYn+lDrW2hxHyMu3C9GjwIOu4LKliRafuHVC9+OTglo93QIqqK0hf1UO5HhEp2woSwQkKQ4niwIa08XxvI5g01k14FAJK+Vi7Tqc1sjVHXqzjCQ6BUmv42TT5ofG/MFo53LMrfRi2K3d6duOPctZKPnyqu/Aw8UWGSMEaxpldAIQHhmJLrF4AwNc0PBnWS5RayZXi+4fpSTnIaNsKrzYn0mOdvPlqhgexws21JOQbYSd5rQ9uxNWfKlWamKTJtyODEyT82MEwHwigW3l/JDWrGjauBz38on0IFzvPg60El3ZJ3FZ/lpQA8ueboxDMzA1YriCKLC6HCceOtz/tKOE4TODlsvT6E7xNZySctr6HUvPhlOOzCisdOY0aOyZdmYmtVKneKj3SZi7Ts9nDLY25klsT6okBJOy8Fsa4gWldy3S5g2PuzfNsHvmqCYt/7sQhKAFqYg1wgfuqyQg60U4cdLE1zxWhqkaIYwCDEsu+Ti7WdXBA0zhVh5wXSrYkvqeLErg5JH6TtvApW12/9BvDlXU8ZWMuanCYIQ9ASXVL7XkmOi2m5gLri3oy1DTl8gQqtmwI3l3UcB/P+lrPD06Taa0w1CHSQQNUAz1htzeeNccItowF/fvMOZZfvaw/GEoIeGsmGVLPuw0d+IKlQyJ54XgZTIbJ/MBNqvEAbawmOOw6hhWPOqcRo9r+xAzDdLhX3LhFR1YfAH4e7QHOFdbCyWvOvEL2raaYCTuC247+Bx1J1JelDRiKuxPgt/nx hQMfa8UM 8B0ldyNLTtfLg05TWBxlE1Z8nX8Bc4aWxhbCTmZxuNQOSPhDcRUI4m7xnFu873QgxQEBvVC1wLbbTqwdd4Rztsfj0QwNwxIZmYu5qS3ievDEFBIYtUGwX2keFLD07S1/8Efs+Q84djW00Pd3T68+HNlFVr3WZ+wez/HFQ5gy3OkMTIAhENx1DGXzocI+SzQxRa5x0i6V4yEThYEUWuwMgjs0eVTO2d0OnnbXdjJQhpsvbXTU8u5MCsbPuQmBJ/i11K2sesbnOU3QU5M58EMo48QvoJ3ugcXNebU5y 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: On Fri, Sep 29, 2023 at 8:08=E2=80=AFAM Johannes Weiner wrote: > > On Thu, Sep 28, 2023 at 06:18:19PM -0700, Yosry Ahmed wrote: > > 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 :) > > I have a weak preference. > > It's definitely a little weird that the v1 controller's behavior > changes based on the v2 mount flag. And that if you want it as an > otherwise exclusive v1 user, you'd have to mount a dummy v2. > > But I also don't see a scenario where it would hurt, or where there > would be an unresolvable conflict between v1 and v2 in expressing > desired behavior, since the memory controller is exclusive to one. > > While we could eliminate this quirk with a simple > !cgroup_subsys_on_dfl(memory_cgrp_subsys) inside the charge function, > it would seem almost punitive to add extra code just to take something > away that isn't really a problem and could be useful to some people. > > If Tejun doesn't object, I'd say let's just keep implied v1 behavior. I agree that adding extra code to take a feature away from v1 is probably too much, but I also think relying on a v2 mount option is weird. Would it be too much to just have a v1-specific flag as well and use cgroup_subsys_on_dfl(memory_cgrp_subsys) to decide which flag to read?