Re: [PATCH v2] cgroup/cpuset-v1: Add missing support for cpuset_v2_mode

[Waiman Long <llong@redhat.com>]

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