Date: Mon, 8 Nov 2004 18:29:23 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: Mipam <mipam@ibb.net> Cc: jhb@freebsd.org Subject: Re: preemption stable under 5.3? Message-ID: <Pine.NEB.3.96L.1041108182215.73102M-100000@fledge.watson.org> In-Reply-To: <Pine.BSO.4.56.0411081345310.6146@ux11.ltcm.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041108182215.73102M-100000>