Messages in this thread | | | Subject | Re: [PATCH] sched: remove resetting exec_start in put_prev_task_rt() | From | Steven Rostedt <> | Date | Fri, 10 Jun 2011 10:58:37 -0400 |
| |
On Fri, 2011-06-10 at 22:48 +0800, Hillf Danton wrote: > On Thu, Jun 9, 2011 at 8:34 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> Resetting exec_start to zero has no negative functionality in RT scheduling, > as shown by Yong. > > After put_prev_task() is called in schedule(), > > put_prev_task(rq, prev); > next = pick_next_task(rq); > clear_tsk_need_resched(prev); > > next is picked. Lets assume that next is not prev, and prev is still on RQ, > then prev's sched_class is changed to CFS while it is waiting on RQ. > After sched_class switch, prev is under CFS charge, and the exec_start field > could be taken into other games. > > In task_hot(), called when migrating task, zeroed exec_start is trapped as > the following. >
How could any of that happen? This is all done under the rq->lock. prev's sched class can not change at this time. Everything you stated is protected by the rq->lock. I don't see any race conditions here.
-- Steve
| |