Re: HEADS UP: debug.mpsafenet behavior changing! (turn it off)

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_at_ 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_at_
> 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"
>