From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 00:48: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 3151516A4CE; Tue, 9 Nov 2004 00:48:12 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D918743D2F; Tue, 9 Nov 2004 00:48:09 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 05E447A440; Mon, 8 Nov 2004 16:48:09 -0800 (PST) Message-ID: <419013C8.1040706@elischer.org> Date: Mon, 08 Nov 2004 16:48:08 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Wilkinson, Alex" References: <20041109003400.GC22640@squash.dsto.defence.gov.au> In-Reply-To: <20041109003400.GC22640@squash.dsto.defence.gov.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org cc: jhb@freebsd.org 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:48:12 -0000 if you have a thread A of high priority and a thread B of low priority then if A is stopped (blocked for some reason) and B is running, then preemption controls or describes what happens when A is unblocked.. With no preemption, A is ubblocked and becomes teh highes priority thread to run **WHEN B RELINQUISHES THE CPU**. With preemption, when A is made runnable, B is IMMEDIATLY packed up, and stored as a temporarily suspended thread and A is immediatly run. Since interrupts are now handled by threads, obviously those threads might be unblocked at any random time. Preemption is needd to ensure that teh interrupts are handled relatively quickly, but it obviously also opens teh gate for all sorts of problems in software that was assuming it wouldn't get preempted. Wilkinson, Alex wrote: >For the benefit of those that are not aware. Can someone please explain what >is meant by 'kernel preemption' and the benefits of it. > >Thanks > > - aW > > 0n Mon, Nov 08, 2004 at 06:29:23PM +0000, 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. > > > Is "Fine-grained network stack locking without Giant" imported in 5.3 or > > is a giant lock networking stack still in 5.3? Bye, > > Giant-free networking is enabled by default in most configurations; there > are some chunks of the network stack that aren't fully MPSAFE, and > typically the kernel will automatically re-cover the network stack with > Giant if one of these is compiled in. Examples are KAME IPSEC (not > FAST_IPSEC) and NETIPX. We hope that locking for these subsystems will > come in the near future. The upshot is that you should see nicely > improved scalability in socket I/O on multiple processors at a time -- > threads or processes can now receive input from socket buffers without > touching the Giant lock, and can often send under similar circumstances, > so if you're running large applications with lots of socket I/O, there > should be much less contention. > > You can increase parallelism in the network stack, especially for > interrupt-driven input from multiple interfaces, by setting > net.isr.enable=1. However, there is at least one known bug that has been > corrected in HEAD but not yet RELENG_5, wherein recv() on UDP sockets can > return the incorrect address when UDP input is ocurring from more than one > thread (without net.isr.enable, UDP input occurs only from the netisr, so > it doesn't occur -- the default). I will be merging the fix to that to > 5-STABLE after it's had another couple of weeks to settle in HEAD. > > In the next couple of weeks I'll also be merging a number of performance > improvements for the network stack that settled into the tree after 5.x > went to the RC series. So you (and others, ideally) should see network > stack performance improve quite a bit over the next month or two if > tracking 5-STABLE. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > >