Hi, On Tue, 11 Dec 2012 12:00:55 +0530, Preeti U. Murthy wrote: > On 12/11/2012 10:58 AM, Alex Shi wrote: >> On 12/11/2012 12:23 PM, Preeti U Murthy wrote: >>> Hi Alex, >>> >>> On 12/10/2012 01:52 PM, Alex Shi wrote: >>>> It is impossible to miss a task allowed cpu in a eligible group. >>> >>> The one thing I am concerned with here is if there is a possibility of >>> the task changing its tsk_cpus_allowed() while this code is running. >>> >>> i.e find_idlest_group() finds an idle group,then the tsk_cpus_allowed() >>> for the task changes,perhaps by the user himself,which might not include >>> the cpus in the idle group.After this find_idlest_cpu() is called.I mean >>> a race condition in short.Then we might not have an eligible cpu in that >>> group right? >> >> your worry make sense, but the code handle the situation, in >> select_task_rq(), it will check the cpu allowed again. if the answer is >> no, it will fallback to old cpu. >>> >>>> And since find_idlest_group only return a different group which >>>> excludes old cpu, it's also imporissible to find a new cpu same as old >>>> cpu. > > I doubt this will work correctly.Consider the following situation:sched > domain begins with sd that encloses both socket1 and socket2 > > cpu0 cpu1 | cpu2 cpu3 > -----------|------------- > socket1 | socket2 > > old cpu = cpu1 > > Iteration1: > 1.find_idlest_group() returns socket2 to be idlest. > 2.task changes tsk_allowed_cpus to 0,1 > 3.find_idlest_cpu() returns cpu2
AFAIK The tsk->cpus_allowed cannot be changed during the operation since it's protected by tsk->pi_lock. I can see the following comment: kernel/sched/core.c: /* * The caller (fork, wakeup) owns p->pi_lock, ->cpus_allowed is stable. */ static inline int select_task_rq(struct task_struct *p, int sd_flags, int wake_flags) { int cpu = p->sched_class->select_task_rq(p, sd_flags, wake_flags); Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/