Messages in this thread | | | Date | Thu, 19 May 2011 09:41:27 +0800 | Subject | Re: [PATCH] sched: correct how RT task is picked | From | Yong Zhang <> |
| |
On Wed, May 18, 2011 at 10:46 PM, Hillf Danton <dhillf@gmail.com> wrote: > On Wed, May 18, 2011 at 9:24 PM, Steven Rostedt <rostedt@goodmis.org> wrote: >> On Wed, 2011-05-18 at 21:19 +0800, Hillf Danton wrote: >> >>> Hi all >>> >>> The patch is prepared again, in which tests for both cpu and >>> nr_cpus_allowed are dropped. >>> >>> The reason to drop nr_cpus_allowed is to make sure that the >>> returned value is correct for both case that cpu == rq->cpu and >>> case that cpu != rq->cpu. >> >> -ENOPARSE >> >> Why would we pick a task that can't migrate? >> > Hi Steven > > For migration, it is the case that cpu != rq->cpu, and > if cpu is allowed by task's affinity, it is bug that task > could not goto cpu because of nr_cpus_allowed since > the nr_cpus_allowed is computed based on the cpus_allowed mask.
But for next_prio(), we just calculate the next highest migratible task for a rq regardless on which cpu that task will run, say we let cpu=rq->cpu to be second parameter of pick_next_highest_task_rt(), IOW, it has the same effect as cpu = -1
Thanks, Yong
-- Only stand for myself
| |