From owner-freebsd-i386@FreeBSD.ORG Fri Nov 12 04:34:09 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 DD06A16A4CE for ; Fri, 12 Nov 2004 04:34:09 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84F3B43D1D for ; Fri, 12 Nov 2004 04:34:09 +0000 (GMT) (envelope-from anurekh@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so392144rns for ; Thu, 11 Nov 2004 20:34:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=rrNGT4Rkm2OfkfzzuhzRtt1mofyENcgNDs4YMbVxPx1GfZB+FJ6iRRs5wkf9nWRyUAeTbgr+whc2eyUCS2KowW/jWxoJNNCbuMN5oKJ1Z30oeKQPtBSp1naiMjoCFubLJAW2OkNnZYcf95y5ri6lobTvVPlOlxtrelHShhsA1os= Received: by 10.38.206.26 with SMTP id d26mr541274rng; Thu, 11 Nov 2004 20:34:08 -0800 (PST) Received: by 10.38.8.23 with HTTP; Thu, 11 Nov 2004 20:34:08 -0800 (PST) Message-ID: Date: Thu, 11 Nov 2004 23:34:08 -0500 From: Anurekh Saxena To: Stephan Uphoff In-Reply-To: <1100213752.78635.32.camel@palm.tree.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1100213752.78635.32.camel@palm.tree.com> 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 Reply-To: Anurekh Saxena 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 04:34:10 -0000 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 dont see why a handler will explicitly call maybe_preempt, but it could try to add some thread to the runqueue. 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 { > /*