On Friday, June 12, 2015 10:51:20 AM Stefan Andritoiu wrote:
> When returning from an interrupt, does it switch directly the thread
> that was interrupted? Or is the scheduler called to choose a thread to
> run (most probable the thread that was interrupted)?
The scheduler is always called to choose. An ithread may have awakened
a more important thread than the originally interrupted thread.
> More specifically, are the sched_choose() or tdq_choose() functions
> called after returning from an IPI?
As I said in my previous reply. This is not always true for IPIs.
Device interrupt handlers that schedule an ithread will schedule the
ithread and possibly preempt to it before returning from the interrupt.
Only when the interrupted thread is resumed does it then fully cleanup
the interrupted stack and execute iret.
> Does an interrupt have it's own thread, or does it run in the context
> of the interrupted thread as in Linux?
Most device interrupts use a dedicated thread. Some device interrupt
handlers do not. A driver can choose to register a non-threaded handler
that runs on the stack of the interrupted thread. However, such handlers
are limited in what they can do and must often defer work to other threads
that they explicitly schedule (such as via a taskqueue).
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to