From owner-freebsd-i386@FreeBSD.ORG Fri Nov 12 18:09:08 2004
Return-Path: <owner-freebsd-i386@FreeBSD.ORG>
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 <freebsd-i386@FreeBSD.org>; 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 <freebsd-i386@FreeBSD.org>; 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 <jhb@FreeBSD.org>)
encrypted SMTP
for <freebsd-i386@FreeBSD.org>; 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 <jhb@FreeBSD.org>
To: Stephan Uphoff <ups@tree.com>
Date: Fri, 12 Nov 2004 10:58:44 -0500
User-Agent: KMail/1.6.2
References: <aa26c8a904111109581723563d@mail.gmail.com>
<aa26c8a90411112034794ff65f@mail.gmail.com>
<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 <freebsd-i386.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-i386>,
<mailto:freebsd-i386-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-i386>
List-Post: <mailto:freebsd-i386@freebsd.org>
List-Help: <mailto:freebsd-i386-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-i386>,
<mailto:freebsd-i386-request@freebsd.org?subject=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 <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.
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org