From owner-freebsd-stable@FreeBSD.ORG Tue Nov 9 00:41:59 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 AA02616A4D2; Tue, 9 Nov 2004 00:41:59 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CFA043D1D; Tue, 9 Nov 2004 00:41:58 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iA90etZg010617; Tue, 9 Nov 2004 11:10:55 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Tue, 9 Nov 2004 11:11:44 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iA90Xdh21259; Tue, 9 Nov 2004 11:03:39 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RZJC04V2; Tue, 9 Nov 2004 11:03:26 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iA90Y1eK022919 ; Tue, 9 Nov 2004 11:04:01 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iA90Y0GT022918; Tue, 9 Nov 2004 11:04:00 +1030 (CST) (envelope-from wilkinsa) Date: Tue, 9 Nov 2004 11:04:00 +1030 From: "Wilkinson, Alex" To: Robert Watson Message-ID: <20041109003400.GC22640@squash.dsto.defence.gov.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: Emanuel Strobl cc: freebsd-stable@freebsd.org cc: Mipam cc: julian@freebsd.org cc: jhb@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:41:59 -0000 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"