From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 00:03:12 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5362816A4CE for ; Tue, 9 Nov 2004 00:03:12 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id B567043D54 for ; Tue, 9 Nov 2004 00:03:11 +0000 (GMT) (envelope-from ups@freebsd.org) Received: (qmail 14731 invoked by uid 89); 9 Nov 2004 00:03:09 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 9 Nov 2004 00:03:09 -0000 Received: (qmail 14706 invoked by uid 89); 9 Nov 2004 00:03:09 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 9 Nov 2004 00:03:09 -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 iA90375R025275; Mon, 8 Nov 2004 19:03:08 -0500 (EST) (envelope-from ups@freebsd.org) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <418FE0E8.1020702@elischer.org> References: <418FE0E8.1020702@elischer.org> Content-Type: text/plain Message-Id: <1099958587.24619.453.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 08 Nov 2004 19:03:07 -0500 Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org cc: John Baldwin cc: Emanuel Strobl cc: Robert Watson cc: Mipam cc: julian@freebsd.org Subject: Re: preemption stable under 5.3? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 00:03:12 -0000 On Mon, 2004-11-08 at 16:11, Julian Elischer wrote: > Robert Watson wrote: > > >On Mon, 8 Nov 2004, Mipam wrote: > > > > > > > >>Thanks for your reply, okay, then i'd like to enable preemption. I > >>noticed it's not in the GENERIC kernel config file. So: options > >>PREEMPTION would suffice to enable it i guess? Any experience with > >>preemption. noticable changes? So the problem: "PREEMPTION triggers > >>frequent hangs" is resolved? Btw, is RELENG_5 also stable or only for > >>early adopters? I really would like to see ule working stable in > >>combination with preemption, but in 5.3 it won't happen. Maybe ule will > >>be enabled later in the 5 series? > >> > >> > > > >There was a series of bugs in the scheduler which got tickled by > >preemption; I'm unclear as to whether they were all resolved before 5.3 or > >whether they require fixes in HEAD that haven't yet been merged. It may > >well be safe, but I make no promises. Hopefully we can trick Julian or > >John into responding to this thread. :-) Having it off by default on 5.3 > >is certainly the more conservative (and reasonable) position, but if it > >helps your environment and appears stable, there should be no reason not > >to turn it on. It should substantially improve latency in interrupt > >processing as well as packet processing. > > > > I think that PREEMPTION with SCHED_4BSD might be ok.. > It's hard to say because it's always harder to prove something correct > than to prove it broken :-) I agree - PREEMPTION should be ok (On head and on 5.3) as far as the SCHED_4BSD is concerned. ( I ran most tests with PREEMPTION and FULL_PREEMPTION) However running with PREEMPTION may expose locking problems elsewhere. I think at least PREEMPTION (and FULL_PREEMPTION?) should be made standard in head for the archs that support them. ( Otherwise locking will never really get exercised on UP systems) > Hopefully with the rush off, we can sit down and try "prove it ok" and > take some cleanup passes over it. > I still owe my wife a significant "chunk-o-time" (TM) however so count > me out for a while . > Hopefully however ups@ is coming online again this week. I recovered enough to at least debug problems and will resume coding tomorrow. Have fun - I will try to hold the ford ;-) Stephan