Messages in this thread | | | Date | Tue, 11 May 1999 14:00:53 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] new scheduler |
| |
On Tue, 11 May 1999, Ingo Molnar wrote:
>On Tue, 11 May 1999, Andrea Arcangeli wrote: >> >> 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 > >wrong. We actively _preempt_ processes on other CPUs, this means that a
If I understand well the only wrong thing I said is point (2). But if you would read better my email I stated clearly that point (2) it not the pure reality, but instead I said that it's a very good approximation of the pure reality.
>preempted process has all rights to try to replace even lesser priority >processes on other CPUs. Your problem might be that you are thinking in
You should rereadd my previous email. I never said it's useless, I have said that it's not worthwile.
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. Also think that the preemted task has prev->processor pointing the only not reschedulable CPU.
>terms of dual-CPU boxes, i'm using a quad one. (btw, even on a dual box it
I am not thinking at dual-CPU I always think without limit of CPU.
>is possible to 'push' a process to another CPU, although it's not the >common case)
I agree that it's possible (I _never_ said the opposite) but my only comment is and was that I am not sure it's really worthwhile. I also said and 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_.
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/
| |