Re: kernel: return from interrupt

On Thursday 11 November 2004 10:59 pm, 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.
>
> Yeah, I got it wrong. Without the FULL_PREEMPTION enabled, it does not
> preempt unless the current thread is in the idle priority band.
> I was expecting the NEEDRESCHED flag to be used for preemption on
> return paths, especially for interrupt context. I think this method
> works better since preemption points become well defined in the
> kernel.
> Thanks for helping me figure this out.

NEEDRESCHED (albeit rather broken at the moment) is used to implement 
preemptino of user threads.  As Robert mentioned above, in-kernel preemption 
is managed via either direct switches in setrunqueue() or deferred 
preemptions via TDF_OWEPREEMPT in critical_exit().

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org