Messages in this thread |  | | From | (Linus Torvalds) | Subject | Re: [patch] scheduler bugfix, SMP, 2.4.0-test7 | Date | 28 Aug 2000 22:09:37 -0700 |
| |
In article <XFMail.20000828195609.dimitris@engr.sgi.com>, Dimitris Michailidis <dimitris@cthulhu.engr.sgi.com> wrote: > >I thought about it some more. Yes, I can tell statically if I am the idle >thread or not, but how do I tell if the process that was running before me on >the CPU is the idle thread?
Ehh.. Color me confused?
Isn't this _exactly_ what you get if you know who the caller is (by having different callers call different routines)?
Basically, the "previous process" that did the schedule, is, by definition, the process that called into the scheduler.
So if we have the idle thread use a special scheduler, we always know that the process that ran previously on the CPU was the idle thread. We will switch _into_ a non-idle thread, and that thread will eventually context switch away through the "normal" scheduler, but we certainly know we used to be idle.
Note that this would require that we do the eip restore slightly differently. Right now we restore eip in the middle of the scheduler, which means that when we schedule to a new process we will continue at the point the new process required. That, I suspect, may be what you were alluding to.
Taking advantage of who called the scheduler would require that we don't play the eip games quite at that point: we'd have to restore the eip of the new process as the very last thing we'd do, rather than in the middle of scheduling. But that would be nice anyway, as the current thing is really hard to think about sometimes.
(The natural way to change eip would be to change it on the stack frame, so that when "schedule()" returns, it just automatically returns to the proper place. We actually do that right now, except we do it inside the "__switch_to" call rather than the scheduler call.)
Hmm. I dunno. But I'd love to get rid of the silly schedule_tail call in "ret_from_fork". AND we'd get the nice idle thread behaviour.
But looking at the implementation, it really looks qutie nasty to implement any other way than the strange way it is done now. So I guess you're right.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |