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
[EMAIL PROTECTED] Principal Research Scientist, McAfee Research
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
