>it is always 'worthwile' to have a correct scheduler. This was the sole
>purpose of all the 2.2.8 scheduler changes!
The previous scheduler was _wasting_ CPU in schedule. Removing the
reschedule_idle() call I am talking about will never waste cpu and such
removal can _only_ improve global performances. The only thing that it can
harm is to decrease a bit the iteractive response. Yesterday I checked
that here I don't need such reschedule_idle also with 100 cpu hog in
background.
>> You mean that a preemted process has all rights to preempt a even lesser
>> priority CPU. But ask you _why_ such process is been preempted. Simply
>> because in general we can see it as the _less_ priority one.
>
>not necesserily, it might as well just be replaced by a RT process ...
If the `prev' process is RT and the `prev' task is been preemted it means
that all other CPUs are just running RT task too. So it wouldn't be
worthwhile again.
>> I repeat that as global design I prefer to have such call in schedule_tail
>> even if according to me it's only a performance _hit_.
>
>it is not a performance hit at all because most processes reschedule
>'voluntarily', ie. they get removed from the runqueue.
I just said you that in such case the call is not needed. To make the
thing more clear I specify that now we are talking about the case where
the task reschedule voluntarily because prev->current become 0 and
need_resched is been set to 1 by the timer irq handler. OK?
If there is a `next' task different from `prev' task it menas that there
are no other idle CPU in the system (enforced by the new design).
And the `prev' task has no way to win against other process in the system
because its goodness will be always 0 (and as just said there can't be
other idle cpu in the system at the same time).
The reason there can't be other cpu idle at the same time is because if
there would be at least one other cpu idle it would been filled at
wake_up_process time (and also a fork starts with a wake_up_process).
>There is one inconsistency left though, if the previous process was
>SCHED_YIELD then we should obviously not push it to other CPUs, because it
>has just given up it's timeslice. (the attached untested patch fixes this)
I just thought about it yesterday: your change below is strictl needed
also to fix the case where we recalculate the counteres and so we was
running prev_goodness two times in the same schedule istance (and the
second time the yield policy was gone away due the first prev_goodnes
call)... But I didn't considered it a show-stopper. But sure I agree with
the patch and I just applyed it here. Thanks ;).
Andrea Arcangeli
-
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/