Date: Thu, 11 Nov 2004 23:49:21 -0500 From: Stephan Uphoff <ups@tree.com> To: Anurekh Saxena <anurekh@gmail.com> Cc: freebsd-i386@freebsd.org Subject: Re: kernel: return from interrupt Message-ID: <1100234961.78635.324.camel@palm.tree.com> In-Reply-To: <aa26c8a90411112034794ff65f@mail.gmail.com> References: <aa26c8a904111109581723563d@mail.gmail.com> <1100213752.78635.32.camel@palm.tree.com> <aa26c8a90411112034794ff65f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2004-11-11 at 23:34, Anurekh Saxena wrote: > On Thu, 11 Nov 2004 17:55:52 -0500, Stephan Uphoff <ups@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 { > > /* > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1100234961.78635.324.camel>