From owner-freebsd-i386@FreeBSD.ORG Fri Nov 12 18:09:08 2004 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97BDF16A4CE for ; Fri, 12 Nov 2004 18:09:08 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F0AC43D31 for ; Fri, 12 Nov 2004 18:09:08 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5720 invoked from network); 12 Nov 2004 18:09:07 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Nov 2004 18:09:07 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iACI92kV053218; Fri, 12 Nov 2004 13:09:03 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Stephan Uphoff Date: Fri, 12 Nov 2004 10:58:44 -0500 User-Agent: KMail/1.6.2 References: <1100234961.78635.324.camel@palm.tree.com> In-Reply-To: <1100234961.78635.324.camel@palm.tree.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411121058.45230.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-i386@FreeBSD.org Subject: Re: kernel: return from interrupt X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 18:09:08 -0000 On Thursday 11 November 2004 11:49 pm, Stephan Uphoff wrote: > On Thu, 2004-11-11 at 23:34, Anurekh Saxena wrote: > > On Thu, 11 Nov 2004 17:55:52 -0500, Stephan Uphoff 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. Yes, I've axed it in my jhb_preemption branch, but haven't had time to test it recently. > > 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 { > > > /* -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org