[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8dafdb1b-e404-4862-836a-0bdf7e6efd23@redhat.com>
Date: Wed, 16 Apr 2025 14:32:32 -0400
From: Waiman Long <llong@...hat.com>
To: "T.J. Mercier" <tjmercier@...gle.com>, Waiman Long <llong@...hat.com>
Cc: Kamalesh Babulal <kamalesh.babulal@...cle.com>, Tejun Heo
<tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
Michal Koutný <mkoutny@...e.com>, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] cgroup/cpuset-v1: Add missing support for
cpuset_v2_mode
On 4/16/25 2:27 PM, T.J. Mercier wrote:
> On Wed, Apr 16, 2025 at 11:05 AM Waiman Long <llong@...hat.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@...cle.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@...gle.com>
>>>> The patch looks good to me, please feel free to add
>>>>
>>>> Reviewed-by: Kamalesh Babulal <kamalesh.babulal@...cle.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
Powered by blists - more mailing lists