HEADS UP: debug.mpsafenet behavior changing! (turn it off)
Robert Watson
rwatson at FreeBSD.org
Sun Mar 28 15:47:14 PST 2004
On Mon, 22 Mar 2004, Robert Watson wrote:
> This is an advance HEADS UP.
This is a reminder e-mail! If you have debug.mpsafenet turned on, please
turn of off for the next few weeks. I'll send out e-mails as things move
along.
I just merged the semantic change to debug.mpsafenet to cover the entire
stack, and will now start pushing Giant into socket-related system calls.
However, I won't be adding most of the new locking until we've done a
review pass on arch@ next week.
Thanks! (remainder of my original post below).
> Over the next two weeks, I'm going to start merging more significant
> parts of the network locking patches. The first change is that the
> definition of debug.mpsafenet is going to chang. Up until now, this
> tunable has meant:
>
> If set, don't hold Giant over the lower levels of the network stack and
> IP forwarding path. If unset, Giant is held over the lower level parts
> of the stack.
>
> This provided substantial performance benefits on SMP and UP for
> forwarding and filtering, but not for locally sourced or sinked network
> traffic (as it didn't release Giant higher in the stack). As we push
> Giant off the higher levels of the stack, we will be changing how
> debug.mpsafenet works. Here's the new definition:
>
> If set, don't hold Giant over any of the network stack, including the
> sockets layer. If unset, Giant is held over all parts of the network
> stack.
>
> It's likely few people are running with debug.mpsafenet; however, if you
> are, this is your warning that you'll probably want to stop running with
> it shortly. With this change, we will be migrating to a dual-mode stack,
> in which you can either run the whole thing with Giant, or none of it.
> This approach is substantially easier to implement than a mixed mode
> stack, in which some pieces are covered with Giant running side by side
> with other pieces that are not. During the migration period to
> fine-grained locking (as patches are merged, etc), it will likely be a
> very bad idea to run with this tunable set, so turn it off now!
> debug.mpsafenet will continue to exist for the forseeable future in some
> form, as it will allow non-MPSAFE network stack components to continue to
> function, at the cost of performance.
>
> In the next few days, I will be posting pretty large patchsets to arch@
> and requesting review and testing. I'll commit a note to UPDATING with
> similar but abbreviated content.
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org Senior Research Scientist, McAfee Research
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
More information about the freebsd-current
mailing list