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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:23 EST