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

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 03/22/04

  • Next message: Divacky Roman: "panic: uma_zfree: Freeing to non free bucket index." 
    Date: Mon, 22 Mar 2004 11:31:37 -0500 (EST)
To: current@FreeBSD.org

    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

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

  • Next message: Divacky Roman: "panic: uma_zfree: Freeing to non free bucket index."

    Relevant Pages

    • Re: Running the network stack without Giant -- change in default coming
      ... > to allow the network stack to run in parallel on multiple processors ... > currently unsafe without the Giant lock turned on. ... > configuration for testing out the impact of disabling Giant on MP ...
      (freebsd-current)
    • Running the network stack without Giant -- what to try and when
      ... As many of you have seen from status reports, e-mails, bug reports, etc, ... the FreeBSD Project has been working for some time on getting the network ... without the Giant lock, and we're ready for more people to start running ... - While we've been doing pretty heavy testing in MPSAFE configurations, ...
      (freebsd-current)
    • Re: Signs of Maccie desperation!
      ... they cannot be implemented in UNIX? ... Network mapping magically detects what your ... Same with the new stack. ... interface, and a ton load of new technologies in the file system, kernel, ...
      (comp.sys.mac.advocacy)
    • Re: Force IP packets on the wire.
      ... direct send handlers, and not throught TDI subsystem, thus the TDI_SEND IRPs ... Ironically, XP builds of stack ... passthru NDIS sample, should not take much time to write a prototype. ... I am writting a network test tool for testing a networked ...
      (microsoft.public.win32.programmer.networks)
    • Removing NET_NEEDS_GIANT: first patch
      ... This source code declaration was used by optionally compiled components to declare a strict requirement for Giant, and forced Giant over the entire network stack. ... retrieving revision 1.13 ... diff -u -r1.13 amrr.c ...
      (freebsd-arch)
    • Quantcast