Re: kernel: return from interrupt

On Mon, 15 Nov 2004 14:33:57 -0500, John Baldwin <jhb_at_freebsd.org> wrote:
> 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().
> 

Yeah,  I think I get the way its done, but it would be nice to be able
to use the NEEDRESCHED flag as a general way to say... we need to
resched, irrespective of which mode we are returning to. I don't know
how much of the code expecrs the current behavior.

I can think of atleast two ways in which the generic flag could be
used.  I don't know whether its a good idea or not. Just a thought.
1> The generic return-from-'some form of interrupt' path can simply
call the scheduler if the flag is set.  Though I cant think of any
examples to provide, but it may be used as a defer flag, just like the
TDF_OWEPREEMPT is used at the moment.
2> A kernel thread that wants to be able to do as much work as it can,
may keep checking this flag and know when to preempt.


Thanks,
-Anurekh