Messages in this thread | | | Date | Sun, 23 Dec 2012 20:17:06 +0800 | Subject | Re: [PATCH 01/18] sched: select_task_rq_fair clean up | From | Alex Shi <> |
| |
On Fri, Dec 21, 2012 at 12:28 PM, Namhyung Kim <namhyung@kernel.org> wrote: > 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:
You are right. I misunderstand some comments in wake_up_new_task.
-- Thanks Alex
| |