Date: Sun, 28 Mar 2004 18:44:52 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: current@FreeBSD.org Subject: Re: HEADS UP: debug.mpsafenet behavior changing! (turn it off) Message-ID: <Pine.NEB.3.96L.1040328184217.35345B-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1040322112622.69952D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Senior Research Scientist, McAfee Research > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040328184217.35345B-100000>