Re: kernel: return from interrupt

On Thu, 11 Nov 2004, Anurekh Saxena wrote:

> > Even normal "options PREEMPTION" should do this.  I know from tracing the
> > kernel in 6.x that that's the way the system behaves out of the box; with
> > PREEMPTION turned on in 5.x you should see the same behavior.  One thing I
> > often do see, FWIW, is that if you're on an SMP box, the ithread will get
> > scheduled to run immediately on another CPU that's idle, so you won't
> > actually preempt the thread on the current CPU other than for the
> > interrupt handler.  What behavior are you seeing that suggests this isn't
> > happening with PREEMPTION compiled in?
> 
> I may be missing something fundamental here, but, doreti (exceptions.s)
> does not call 'ast' for an interrupted task, that does not have RPL of 3
> (user).  So, even if an interrupt is pending, and the 'NEEDRESCHED' is
> set, the scheduling decision is delayed till the kernel thread or
> whatever was running in the kernel sleeps, or give up the cpu(call
> mi_switch), or returns to user mode. 
> 
> AFAIK this is the only return path from an interrupt. Unless there is
> another return path for the interrupts, the scheduler is not invoked on
> a return. 

Assuming we're talking about i386, lapic_handle_intr() will call
intr_execute_handlers(), which will walk the list of handlers for the
interrupt, and either directly invoke the fast handlers of the interrupts,
or call ithread_schedule() to schedule the ithread.  ithread_schedule() 
will invoke setrunqueue(), which enters the scheduler and is a preemption
point.  If you dig down a bit, you'll find a call to maybe_preempt(),
which may preempt if appropriate, resulting in a call to mi_switch() to
the ithread.  The maybe_preempt() code will only kick in to actually
switch if PREEMPTION is defined.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research