Hi
On 03/27/06 07:45, Oliver Yang wrote:
Gavin Maltby wrote:
The call to preempt from sparc interrupt.s is to avoid interrupts running
endlessly on a cpu while pinning an interrupted thread (which could run
on another cpu if only we'd unpin it). In sparc new interrupts can be
queued at the pil we're servicing even while we are serviving preexisting
requests (new requests come in at traplevel 1 via vec_interrupt).
x86 does not require this check.
Sorry, I'm not familiar with Sparc platform.
As I known, cmnint routine will mask same or below level's interrupt by
calling psm_intr_enter.
Does it means sparc CPU don't mask the interrupt at same level?
In sparc the "level interrupts" are just another trap type, and they have
lower priority than the "vector interrupt" trap. So while servicing
a level N interrupt you can't take any other level interrupts at level N
or below (enforced through the level interrupts having different
priority levels) but you can take higher-priority traps including
vector interrupt. Vector interrupt is what you get when an interrupt
packet ("mondo") arrives from another cpu or an IO bridge device.
That flag is t_astflag in the thread structure - you'll see it
checked in user_rtt for sparc and in lwp_rtt for x86.
Exactly how you get there is left as an exercise (ie it
is convoluted).
Yeah, after reading source code again, I know poke_cpu can cause other
CPU's preemption via a crosscall.
Finally, I found the entry point of rtt code for x86 platform:
[cut]. A quick note, if you have the option available, is that this
low-level fiddly stuff can sometimes be nicely observed through
running Solaris as a guest on some form of simulator - you use
the simulators debugger to follow the code flow in Solaris.
But poke_cpu is just called for other cpu, not current thread's cpu.
For current thread's cpu or a UP system, the user preemptions only
happen when syscall, trap or interupt (typically, clock interrupt) return.
That's my understanding, is it right?
It's true that much scheduling happens at the granularity of the
clock tick. The cpu that performs the clock tick processing (usually stays the
same)
will look around at all cpus including itself and see which threads
need to be kicked off cpu. The other common way for a thread to
get off cpu is for it to volunteer - eg it blocks on a condvar and
gives up cpu by calling swtch() (eg see cv_wait).
It seems AST trap is not only used for user preemtion but also for
process signal mechanism. Maybe I can work out how it work in folloing
days.
Sounds like you're into pain :-)
Anyway, your reply is valuable for me, thank you!
No problem - we'll be happy to help with any other queries that we have any
relevant experise for.
Cheers
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
