From: Waiman Long <llong@redhat.com>
To: Chen Ridong <chenridong@huaweicloud.com>,
Waiman Long <llong@redhat.com>,
tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
lujialin4@huawei.com, chenridong@huawei.com,
christophe.jaillet@wanadoo.fr
Subject: Re: [-next v2 4/4] cpuset: add helpers for cpus read and cpuset_mutex locks
Date: Wed, 13 Aug 2025 23:13:44 -0400 [thread overview]
Message-ID: <93e37ccf-8ac8-40f5-840f-2f221f58131e@redhat.com> (raw)
In-Reply-To: <750ac0bd-42f9-47fa-8274-0ff4e4a7fa3d@huaweicloud.com>
On 8/13/25 8:44 PM, Chen Ridong wrote:
>
> On 2025/8/14 4:09, Waiman Long wrote:
>> On 8/13/25 4:29 AM, Chen Ridong wrote:
>>> From: Chen Ridong <chenridong@huawei.com>
>>>
>>> cpuset: add helpers for cpus_read_lock and cpuset_mutex
>>>
>>> Replace repetitive locking patterns with new helpers:
>>> - cpus_read_cpuset_lock()
>>> - cpus_read_cpuset_unlock()
>>>
>>> This makes the code cleaner and ensures consistent lock ordering.
>>>
>>> Signed-off-by: Chen Ridong <chenridong@huawei.com>
>>> ---
>>> kernel/cgroup/cpuset-internal.h | 2 ++
>>> kernel/cgroup/cpuset-v1.c | 12 +++------
>>> kernel/cgroup/cpuset.c | 48 +++++++++++++++------------------
>>> 3 files changed, 28 insertions(+), 34 deletions(-)
>>>
>>> diff --git a/kernel/cgroup/cpuset-internal.h b/kernel/cgroup/cpuset-internal.h
>>> index 75b3aef39231..6fb00c96044d 100644
>>> --- a/kernel/cgroup/cpuset-internal.h
>>> +++ b/kernel/cgroup/cpuset-internal.h
>>> @@ -276,6 +276,8 @@ int cpuset_update_flag(cpuset_flagbits_t bit, struct cpuset *cs, int turning_on)
>>> ssize_t cpuset_write_resmask(struct kernfs_open_file *of,
>>> char *buf, size_t nbytes, loff_t off);
>>> int cpuset_common_seq_show(struct seq_file *sf, void *v);
>>> +void cpus_read_cpuset_lock(void);
>>> +void cpus_read_cpuset_unlock(void);
>> The names are not intuitive. I would prefer just extend the cpuset_lock/unlock to include
>> cpus_read_lock/unlock and we use cpuset_lock/unlock consistently in the cpuset code. Also, there is
>> now no external user of cpuset_lock/unlock, we may as well remove them from include/linux/cpuset.h.
>>
>> Cheers,
>> Longman
> I like the idea and have considered it.
> However, I noticed that cpuset_locked is being used in __sched_setscheduler.
Right, I overloooked the cpuset_lock() call in kernel/sched/syscall.c.
So we can't remove it from include/linux/cpuset.h.
This call is invoked to ensure cpusets information is stable. However,
it doesn't hurt if the cpus_read_lock() is also acquired as a result.
Alternatively, we can use a name like cpuset_full_lock() to include
cpus_read_lock().
Cheers,
Longman
next prev parent reply other threads:[~2025-08-14 3:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 8:29 [-next v2 0/4] some optimization for cpuset Chen Ridong
2025-08-13 8:29 ` [-next v2 1/4] cpuset: remove redundant CS_ONLINE flag Chen Ridong
2025-08-13 18:15 ` Tejun Heo
2025-08-13 8:29 ` [-next v2 2/4] cpuset: decouple tmpmaks and cpumaks of cs free Chen Ridong
2025-08-13 19:50 ` Waiman Long
2025-08-14 0:38 ` Chen Ridong
2025-08-13 8:29 ` [-next v2 3/4] cpuset: separate tmpmasks and cpuset allocation logic Chen Ridong
2025-08-13 21:28 ` kernel test robot
2025-08-15 0:44 ` Chen Ridong
2025-08-15 19:15 ` Waiman Long
2025-08-16 0:21 ` Chen Ridong
2025-08-13 8:29 ` [-next v2 4/4] cpuset: add helpers for cpus read and cpuset_mutex locks Chen Ridong
2025-08-13 20:09 ` Waiman Long
2025-08-14 0:44 ` Chen Ridong
2025-08-14 3:13 ` Waiman Long [this message]
2025-08-14 3:27 ` Waiman Long
2025-08-14 3:58 ` Chen Ridong
2025-08-15 19:13 ` Waiman Long
2025-08-16 0:23 ` Chen Ridong
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=93e37ccf-8ac8-40f5-840f-2f221f58131e@redhat.com \
--to=llong@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huawei.com \
--cc=chenridong@huaweicloud.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lujialin4@huawei.com \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.