From: Waiman Long <llong@redhat.com>
To: "T.J. Mercier" <tjmercier@google.com>, Waiman Long <llong@redhat.com>
Cc: "Kamalesh Babulal" <kamalesh.babulal@oracle.com>,
"Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] cgroup/cpuset-v1: Add missing support for cpuset_v2_mode
Date: Wed, 16 Apr 2025 14:32:32 -0400 [thread overview]
Message-ID: <8dafdb1b-e404-4862-836a-0bdf7e6efd23@redhat.com> (raw)
In-Reply-To: <CABdmKX2Basoq0Sk6qemcP3Mne6-nJPNN0Mz9WYjvdKWNagoaZg@mail.gmail.com>
On 4/16/25 2:27 PM, T.J. Mercier wrote:
> On Wed, Apr 16, 2025 at 11:05 AM Waiman Long <llong@redhat.com> wrote:
>> On 4/16/25 1:55 PM, T.J. Mercier wrote:
>>> On Wed, Apr 16, 2025 at 2:19 AM Kamalesh Babulal
>>> <kamalesh.babulal@oracle.com> wrote:
>>>> Hi,
>>>>
>>>> On 4/16/25 5:23 AM, T.J. Mercier wrote:
>>>>> Android has mounted the v1 cpuset controller using filesystem type
>>>>> "cpuset" (not "cgroup") since 2015 [1], and depends on the resulting
>>>>> behavior where the controller name is not added as a prefix for cgroupfs
>>>>> files. [2]
>>>>>
>>>>> Later, a problem was discovered where cpu hotplug onlining did not
>>>>> affect the cpuset/cpus files, which Android carried an out-of-tree patch
>>>>> to address for a while. An attempt was made to upstream this patch, but
>>>>> the recommendation was to use the "cpuset_v2_mode" mount option
>>>>> instead. [3]
>>>>>
>>>>> An effort was made to do so, but this fails with "cgroup: Unknown
>>>>> parameter 'cpuset_v2_mode'" because commit e1cba4b85daa ("cgroup: Add
>>>>> mount flag to enable cpuset to use v2 behavior in v1 cgroup") did not
>>>>> update the special cased cpuset_mount(), and only the cgroup (v1)
>>>>> filesystem type was updated.
>>>>>
>>>>> Add parameter parsing to the cpuset filesystem type so that
>>>>> cpuset_v2_mode works like the cgroup filesystem type:
>>>>>
>>>>> $ mkdir /dev/cpuset
>>>>> $ mount -t cpuset -ocpuset_v2_mode none /dev/cpuset
>>>>> $ mount|grep cpuset
>>>>> none on /dev/cpuset type cgroup (rw,relatime,cpuset,noprefix,cpuset_v2_mode,release_agent=/sbin/cpuset_release_agent)
>>>>>
>>>>> [1] https://cs.android.com/android/_/android/platform/system/core/+/b769c8d24fd7be96f8968aa4c80b669525b930d3
>>>>> [2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libprocessgroup/setup/cgroup_map_write.cpp;drc=2dac5d89a0f024a2d0cc46a80ba4ee13472f1681;l=192
>>>>> [3] https://lore.kernel.org/lkml/f795f8be-a184-408a-0b5a-553d26061385@redhat.com/T/
>>>>>
>>>>> Fixes: e1cba4b85daa ("cgroup: Add mount flag to enable cpuset to use v2 behavior in v1 cgroup")
>>>>> Signed-off-by: T.J. Mercier <tjmercier@google.com>
>>>> The patch looks good to me, please feel free to add
>>>>
>>>> Reviewed-by: Kamalesh Babulal <kamalesh.babulal@oracle.com>
>>>>
>>>> One nit below:
>>>>
>>>>> ---
>>>>> kernel/cgroup/cgroup.c | 29 +++++++++++++++++++++++++++++
>>>>> 1 file changed, 29 insertions(+)
>>>>>
>>>>> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
>>>>> index 27f08aa17b56..cf30ff2e7d60 100644
>>>>> --- a/kernel/cgroup/cgroup.c
>>>>> +++ b/kernel/cgroup/cgroup.c
>>>>> @@ -2353,9 +2353,37 @@ static struct file_system_type cgroup2_fs_type = {
>>>>> };
>>>>>
>>>>> #ifdef CONFIG_CPUSETS_V1
>>>>> +enum cpuset_param {
>>>>> + Opt_cpuset_v2_mode,
>>>>> +};
>>>>> +
>>>>> +const struct fs_parameter_spec cpuset_fs_parameters[] = {
>>>>> + fsparam_flag ("cpuset_v2_mode", Opt_cpuset_v2_mode),
>>>>> + {}
>>>>> +};
>>>> A minor optimization you may want to convert the cpuset_fs_parameters into
>>>> a static const.
>>> Thanks, I copied from cgroup1_fs_parameters since that's where
>>> cpuset_v2_mode lives, which doesn't have the static currently
>>> (cgroup2_fs_parameters does). Let me update cpuset_fs_parameters in
>>> v3, and add a second patch for cgroup1_fs_parameters.
>> Besides not exposing the structure outside the current file or maybe a
>> tiny bit of linker speedup, is there other performance benefit by adding
>> "static"?
>>
>> Regards,
>> Longman
>>
> I thought it might decrease the text size a tiny bit, but it doesn't
> because the symbol isn't exported and I guess the compiler knows to
> just inline.
>
Since the structure already have a "const" modifier, I doubt there is
any further optimization that the compiler can do whether the symbol is
visible externally or not. Anyway, I am not objecting to v3 with static
modifier added.
Cheers,
Longman
next prev parent reply other threads:[~2025-04-16 18:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 23:53 T.J. Mercier
2025-04-16 1:07 ` Waiman Long
2025-04-16 9:19 ` Kamalesh Babulal
2025-04-16 17:55 ` T.J. Mercier
2025-04-16 18:00 ` T.J. Mercier
2025-04-16 18:05 ` Waiman Long
2025-04-16 18:27 ` T.J. Mercier
2025-04-16 18:32 ` Waiman Long [this message]
2025-04-16 9:29 ` Michal Koutný
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8dafdb1b-e404-4862-836a-0bdf7e6efd23@redhat.com \
--to=llong@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kamalesh.babulal@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®