lkml.org 
[lkml]   [2022]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v4 3/3] cgroup/cpuset: Keep user set cpus affinity
From
On 8/16/22 13:52, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 16, 2022 at 01:38:17PM -0400, Waiman Long wrote:
>> Yes, a race like this is possible. To completely eliminate the race may
>> require taking task_rq_lock() and then calling
>> __set_cpus_allowed_ptr_locked() which is internal to kernel/sched/core.c.
>>
>> Alternatively, we can check user_cpus_ptr again after the scond
>> set_cpus_allowed_ptr() and retry it with the other path if set. That will
>> probably address your concern. Please let me know if you are OK with that.
> I think this would look better if structured the other way around - make the
> scheduler side call out to cpuset to query the current restrictions and
> apply it atomically.

The sched_setaffinity() function does call cpuset_cpus_allowed() to
apply the cpuset constraint. However, making set_cpus_allowed_ptr() call
cpuset function is a major change. It will disturb the current locking
sequences and may cause circular locking dependency problem. We
certainly need more time to figure out if that is feasible.

In the mean time, I would prefer to do a retry if user_cpus_ptr status
changes for now. We can then do a follow up patch to make this
structural change if there is a consensus of doing so.

Cheers,
Longman

\
 
 \ /
  Last update: 2022-08-16 20:22    [W:3.225 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site