kernel: return from interrupt

[Stephan Uphoff]

On Thu, 2004-11-11 at 23:34, Anurekh Saxena wrote:
> On Thu, 11 Nov 2004 17:55:52 -0500, Stephan Uphoff <ups at tree.com> wrote:
> > On Thu, 2004-11-11 at 12:58, Anurekh Saxena wrote:
> > 
> > 
> > > Hi,
> > >
> > > I was under the impression that the 5.3 release had an option for full
> > > preemption.
> > > If I am correct, why does the kernel refuse to schedule on a
> > > return_from_interrupt if its not
> > > going back to userland?
> > > I can understand this being a problem if interrupts were nested, or
> > > return from a page fault in a
> > > critical section.
> > > Please correct me if I am wrong, but if a *high* priority interrupt
> > > thread is ready to run, it
> > > should be given a chance. Presuming the *interrupted* kernel path is
> > > going to give up the CPU
> > > fast enough is probably not a good idea.
> > >
> > >
> > > I hope I have sent this to the right mailing list.
> > >
> > > Thanks,
> > > Anurekh
> >  
> > This should work if you have "options PREEMPTION" in your config file.
> > You may also want to try "options FULL_PREEMPTION".
> 
> I wasnt looking at the  FULL_PREEMPTION option at all. With that
> enabled, the kernel will
> call mi_switch when it adds the thread to the runqueue. Thanks for the input.
> 
> > Can you describe your problems / observations?
> 
> I was expecting the common return_from_intr path to be used as a
> preemption point.
> It was an incorrect observation, and also probably wouldn't work with
> the ast implementation.
> 
> > The exception seems to be fast interrupts.
> > You may want to try the following untested patch to allow preemption
> > triggered by fast interrupts.
> 
> That is interesting. I didn't see that the OWEPREEMPT flag is
> deliberately cleared.
> Do you why that is done?

I assume that this is just a forgotten temporary fix for scheduler
problems. I will try to verify this in the next days.


>  I dont see why a handler will explicitly call
> maybe_preempt, but it
> could try to add some thread to the runqueue.

wakeup and scheduling soft interrupt threads would come to mind.


> 
> Thanks for the feedback.
> 
> -Anurekh
> > Index: intr_machdep.c
> > ===================================================================
> > RCS file: /cvsroot/src/sys/i386/i386/intr_machdep.c,v
> > retrieving revision 1.11
> > diff -u -r1.11 intr_machdep.c
> > --- intr_machdep.c      3 Nov 2004 18:03:06 -0000       1.11
> > +++ intr_machdep.c      11 Nov 2004 22:31:19 -0000
> > @@ -205,7 +205,9 @@
> >                 isrc->is_pic->pic_eoi_source(isrc);
> >                 error = 0;
> >                 /* XXX */
> > +#if 0
> >                 td->td_pflags &= ~TDP_OWEPREEMPT;
> > +#endif
> >                 critical_exit();
> >         } else {
> >                 /*
> 
>