Hi,
On 02/12/07 18:41, Haris wrote:
Hi -
Relating to my previous post about g7, It would be nice if someone could give
me an idea of the call path followed at a context switch. Suppose we are a user
thread and our quantum expires; which functions will be invoked? (timer
interrupt, get into kernel, invoke dispatcher? ).
Whether we block, voluntarily give up cpu, reach our quantum, are preempted etc
we land up in swtch() or swtch_to(), and call resume() from there either for
the new
thread to run or otherwise the idle thread.
In resume() we begin by shuffling the old thread off of cpu and preserving its
register state etc, and then we make as if the idle thread is on cpu and
go to resume_from_idle (just to share code for the two paths - switching from
a real thread to another, or the cpu idle thread to another).
In resume_from_idle we setup to run the new thread. Part of this is to update
THREAD_REG (and we have to be very careful regarding the validity of TRHEAD_REG
and what event we can allow to happen, such as interrupts) but we also
need to restore integer register state, fpu state if appropriate etc. We also
need to change the context register to that of the new process, if it's from
a different address space to the outgoing thread. resume_from_idle also
plays with the return linkage such that when we return from that function
we continue running at the point we wish to resume the new thread - the
top half of resume_from_idle runs with the context of the outgoing/idle
thread and the last bit with that of the resuming thread.
As to how we get preempted, kicked off for quantum expire etc there's tonnes
to describe there. However it is perhaps best explored via dtrace.
Start by looking at stacks for callers of things like setfrontdq
and setbackdq. You will also want to explore the scheduler code
in the clock() function in clock.c; the clock ticks at 100Hz
by default and among other activities counts down the quantum of
threads on cpu in the timeshare class; if you run out of quantum and
someone else wants the cpu a flag is set in the cpu structure for
the cpu you're on (cpu_runrun or cpu_kprunrun) and the cpu is forced
to take a trivial trap via a "poke" at it. In the return-from-trap
processing code (see user_rtt and ast processing there) it will
notice the flag in the cpu structure and begin to arrange that the
thread currently on cpu get off cpu.
Hope that helps.
Cheers
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
