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 82BB1E71D40 for ; Fri, 29 Sep 2023 15:08:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81D1C6B00BD; Fri, 29 Sep 2023 11:08:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A5CF6B00BE; Fri, 29 Sep 2023 11:08:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D1A56B00BF; Fri, 29 Sep 2023 11:08:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4372A6B00BD for ; Fri, 29 Sep 2023 11:08:34 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 1ACC0A0C7E for ; Fri, 29 Sep 2023 15:08:34 +0000 (UTC) X-FDA: 81289966548.13.522BA85 Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) by imf24.hostedemail.com (Postfix) with ESMTP id 273AD180003 for ; Fri, 29 Sep 2023 15:08:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=RkpllHDq; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.173 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696000112; 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=eIoMc56bIfBZy6/PdEQktEjOwAzqVOREk+ePKY8LOlo=; b=RPYOfzntqah3bUxoO6rDJSWNakMO3nmTCtlOMkzvEypP9tM0nsJGL3qcpnlct8JYkG/Zzv JjFv35K7hYP9kmxOFa/KnZO8rOUNUc5VjTjdgkFtuQqi+PZ8vJ9i0q0PILAmnX+T5556im oo9376u9IqoNf+4GxyiHW5xlV2lWFCI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=RkpllHDq; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.173 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696000112; a=rsa-sha256; cv=none; b=8BzFc8WD18iBf/ul6bXxD5EUdwRrHmp+LhJOh2zDspCFbcDLYQJLD1ak82VErR3jUc56mp o5QSU/wvR4OFixk9Fr2RJhePN9ERdw5BTaFWycZabY9GKqpPBrkZzQ37rQgtE5cwJ10qcu Lx64n88YMdG6QqVZ/SWc+YTKyZ5RBmc= Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-7740c8509c8so891483885a.3 for ; Fri, 29 Sep 2023 08:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1696000111; x=1696604911; 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=eIoMc56bIfBZy6/PdEQktEjOwAzqVOREk+ePKY8LOlo=; b=RkpllHDqr686p3FUdIY4Jz15eJPgWFMsqhw9YbgEgh9corPWhIjn+NYcy7vjNjCJcl 8edvnGA8K3T/DF/1Pde6KYaw2uAfv6eTvOIk02JFhRj4+ptARbZUVQVeniLffQBmM6c4 BzGD1HkxSBAERAxFXBEXrzwU2vx+4I7qcbubBC4I47iaUGMBTHM3VqSjp8/vWrJ9GYQM 0QFYhDHiOgdEpdPToFNXT4zdiay6MwTymHY3TgEDt9oKAwTArxk+wxdd09TM7kKK8tzs pp9hD1pQZ4cDJmvZZ+3wPIQlG90IdHFxNUMOzLAEohbxdoiYE/l8ep6yWWIml6ergXzU CC+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696000111; x=1696604911; 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=eIoMc56bIfBZy6/PdEQktEjOwAzqVOREk+ePKY8LOlo=; b=jEsNqSd95qdsTFx3fODtgs0YezrJRI0qeDa/vvlgljb8SJfBkLwuFi8Jq8VCGgulCQ AjtX5wE0z3wTxuK8rNQGXN/lNyI8NnCAsnpFXx64qw4Yi/Xd+zayA9kheu4sG6nFOp+A aYHCQfbc9bsiRO3c25l4Qdqru6RN9KQXILv2nxPiOMXw82ukM1KnGK05b0c/euiyF2zN YItFSExVGFS2f8vyWB8pwf2JCInnHTw6pqRT8P09Jym7JfiRthrftC+1aZ0RothUhsna FGtMOYanRJB9f0GmHd/aynaJpF7NcNrhMsX++Ryc/+G/z8Qvfwgy67uIVwEhublJ8Fc4 hTmA== X-Gm-Message-State: AOJu0YwkLRW7T6ozZTcPDqeYdj1lsNOiWpHjMamUYLdMBHhgf+uDvdp9 wXlknQdNkKPmVmTE563LmUSyJQ== X-Google-Smtp-Source: AGHT+IHV/YhrWHzDQ207LDHTmLp/zJOODiEdUhE2mMsIH7bmfSsTIGwBXN4fFashJ84I4V1XDq3Rdg== X-Received: by 2002:a05:620a:bc1:b0:76d:90c9:595b with SMTP id s1-20020a05620a0bc100b0076d90c9595bmr4744478qki.24.1696000111010; Fri, 29 Sep 2023 08:08:31 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:a683]) by smtp.gmail.com with ESMTPSA id q21-20020ae9e415000000b00767177a5bebsm6959059qkc.56.2023.09.29.08.08.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Sep 2023 08:08:30 -0700 (PDT) Date: Fri, 29 Sep 2023 11:08:29 -0400 From: Johannes Weiner To: Yosry Ahmed 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 Subject: Re: [PATCH v2 1/2] hugetlb: memcg: account hugetlb-backed memory in memory controller Message-ID: <20230929150829.GA16353@cmpxchg.org> References: <20230928005723.1709119-1-nphamcs@gmail.com> <20230928005723.1709119-2-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 273AD180003 X-Stat-Signature: zyj3jjd3y4tudo7gc967gzzpi7qtdyzf X-HE-Tag: 1696000111-540306 X-HE-Meta: U2FsdGVkX1/EFcYbMBZgoNoecVdmaW270RjdGIqjwAKH6gR0Osc8MBhbbO6iR6gVaOA4dV4P53eJxv8M6wxUWdD0SDIaRzry9lJa5pTxZdTI5v8aCz8mtGfsjzwVEngjTFizUdBLB3UypQihgUxmQ+1UW879sjd/8Zjr+4V6DjKMfC+0b+vydqJbgGUHBKCaMpkaF19srINr5WUe+pmR1Q31m2O4EQPtz8cIHm4OtXhmFtMcw6oDNWULt7hYpqlgveI3qrCsEpkqrXtaUoxq+krMWwGXR3ahKdFc0UlmvzUushRzESBl0GONkmkvMFvWnHMDmCF1tZJYoKhTiKW+Wx9HlOZSGoIh1qtVhfF9wKj5tz3Cbd2IUkFfmeTYyZ84ssn25FPlDyv+pDAAss1PBvJHepCDb76LhXWOvn+zmAY+JLgu3os+h8XQtsWiiUp5vsdTFW9W0wm1Z5tQ1HD2Ewis0VmfP2AN+vRbDgFf2Xw1gaZ8GdDUvbeubfkC9/JAm6e+su5fLPp3TRDSx2DdJgV1A1Dx+rOb1CeYo6+aCG1U/LtV64Q0SPTBkG5ePSAOToA4dkgkpODEjN/lGPb3FVawX4DFCNz+zgK/QSLKnbaDc4pg4MOrqZsxp9bvYNl22qgF1ZjeXmUnBGExunpE7v8KMgENHDp8RomqRNuKvTSU+kPS9n4T95H2klUXpleCmbmLy96i4sSYTs3ETWMk5WjiRHOeHHH01tH223LuqNSrbtPGHz9c+MTn3MT70L1jMqWezGRfI6B+EcgDjll05SRbAl2Gv9S8qBSwjY3FUOgJmJRYlU1ocC5n/rtjLj/PbyvFeFhFr1ZhbcIOUZozzwqlqIUf6u+j/bzkhgR4qIfXO0EQEphhW5Gj5rtoCkiDsJfnaRuWHbZbgxMtFwcdl6aScIi9qY+wSMHNukAhvMIe+mFcpY+1FhnmByxxC5z1LW1iIDz9v/Nqu1iqnL7 z0QRE31M rp+Gg/tjD6Lz1LJccGYfOpl2/ij+1k/cq+GX4JMlqcqQEL+UffP2+0NO+xRXA3jafMKisKJMC4sxVTb/Eyxlt25J2+QgS5RQto4fb6fhtfLobjeiGm/jqwZ6u0DACuq3tfmOXBHPtFU5UZhTD2QqZoyYNiv8HRGKbDTVQDUXgqqktmfESEdvTIvwlvp3Vu3tkkBNdcA3PT+lE0qd63lLEHEqNalnmhr4tAu3PRRaUJ2XI5ZMO5vcF1vOtIWkwBLdWRq2FnWQ2Q49P9rfqZhQHW98PH1Hhe2ZLsVm2Kd9PtNZy2uI/U6R+SNP6zTuPIdX/rX4dwnTteDmdMK49CQlBbaL5GgCqtMeg8HU8WX7D4BFDe1THLTX2KPd4BmZJPcamj41NptIRMtBPvh3VzjaBjswxe3tiCrx8VfKtzItKKGKNVYI= 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 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.