Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Mar 2004 11:31:37 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        current@FreeBSD.org
Subject:   HEADS UP: debug.mpsafenet behavior changing!  (turn it off)
Message-ID:  <Pine.NEB.3.96L.1040322112622.69952D-100000@fledge.watson.org>

next in thread | raw e-mail | index | archive | help

This is an advance HEADS UP.  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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040322112622.69952D-100000>