Messages in this thread | | | Date | Sun, 9 Jun 2013 23:59:36 +0800 | Subject | Question regarding put_prev_task in preempted condition | From | Lei Wen <> |
| |
Hi Peter,
While I am checking the preempt related code, I find a interesting part. That is when preempt_schedule is called, for its preempt_count be added PREEMPT_ACTIVE, so in __schedule() it could not be dequeued from rq by deactivate_task.
Thus in put_prev_task, which is called a little later in __schedule(), it would call put_prev_task_fair, which finally calls put_prev_entity. For current task is not dequeued from rq, so in this function, it would enqueue it again to the rq by __enqueue_entity.
Is there any reason to do like this, since entity already is over rq, why need to queue it again?
And if current rq's vruntime distribution like below, and vruntime with 8 is the task that would be get preempted. So in __enqueue_entity, its rb_left/rb_right would be set as NULL and reinserted into this RB tree. Then seems to me now, the entity with vruntime of 3 would be disappeared from the RB tree. 13 / \ 8 19 / \ 3 11
I am not sure whether I understand the whole process correctly... Would the example as above happen in our real life?
Thanks, Lei
| |