Messages in this thread | | | Date | Fri, 10 Jun 2011 23:12:56 +0800 | Subject | Re: [PATCH] sched: remove resetting exec_start in put_prev_task_rt() | From | Hillf Danton <> |
| |
On Fri, Jun 10, 2011 at 10:58 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > 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. >
Hi Steve
Yeah you are right, the snippet in schedule() is under RQ lock, but next could be a RT task, and if it is FIFO and willing to hog CPU ie. 10 minutes, then prev has to wait on its RQ. While waiting, however, its sched_class could be changed at anytime. Here I show it is tiny possible that zeroed exec_start could rush out of our control.
thanks Hillf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |