From owner-freebsd-i386@FreeBSD.ORG Thu Nov 11 22:55:55 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 3781916A4CE for ; Thu, 11 Nov 2004 22:55:55 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id BEEA643D1F for ; Thu, 11 Nov 2004 22:55:54 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 1355 invoked by uid 89); 11 Nov 2004 22:55:53 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 11 Nov 2004 22:55:53 -0000 Received: (qmail 1350 invoked by uid 89); 11 Nov 2004 22:55:53 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 11 Nov 2004 22:55:53 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id iABMtq5R078947; Thu, 11 Nov 2004 17:55:53 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Anurekh Saxena In-Reply-To: References: Content-Type: text/plain Message-Id: <1100213752.78635.32.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 11 Nov 2004 17:55:52 -0500 Content-Transfer-Encoding: 7bit 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: Thu, 11 Nov 2004 22:55:55 -0000 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". Can you describe your problems / observations? The exception seems to be fast interrupts. You may want to try the following untested patch to allow preemption triggered by fast interrupts. 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 { /*