>
>On Mon, 10 May 1999, Rik van Riel wrote:
>
>> that need to be done (now that the scheduling seems to
>> be good enough in 2.2.8, with only a superfluous
>> reschedule_idle() in schedule_tail()).
>
>why do you think it is superfluous?
The reschedule_idle() in schedule_tail is there only to handle the case
where the `prev' task is been rescheduled due a reschedule_idle()
call (##).
But if it's been rescheduled due a reschedule_idle() it means that:
1) there are no idle cpu in the system
2) the prev task was in general the less priority one
(2) is not always true, because maybe the `next' task choosed to
reschedule the `prev' task because the prev task was running in the
next->processor CPU for example and never looked at the other CPU maybe
because avg_slice is < cacheflush_time (I have to admit that I am thinking
about my own reschedule_idle core here...). But then `prev' will see all
other task in all other CPU as less good because prev->processor is now
set to the only not rescedulable CPU. Basically such call make sense
mostly for the iteraction of the avg_slice/lock_depth/mm heuristics inside
reschedule_idle().
My point in general was that (2) is near to be the true reality so I am
not sure it worth to do such call in schedule_tail.
As last comment I don't dislike such reschedule_idle call too much since
as global design seems the right thing to do even if I think it's not
worthwhile.
Andrea Arcangeli
(##) if the `prev' task is been rescheduled due the expiration of its
timeslice and there is a task in the runqueue, it means that there are no
idle CPU in the system otherwise reschedule_idle would have just filled
them properly (also a forked task starts with a wakeup). And when a task
expire its timeslice such task can't win anymore against other running
tasks in reschedule_idle (so no point for try it).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/