Re: kernel: return from interrupt

> > > 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.

-Anurekh