Re: Network Stack Locking

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 05/24/04

  • Next message: Daniel Eischen: "Re: atomic reference counting primatives." 
    Date: Mon, 24 May 2004 15:18:09 -0400 (EDT)
To: Eivind Eklund <eivind@FreeBSD.org>

    On Mon, 24 May 2004, Eivind Eklund wrote:

    > On Fri, May 21, 2004 at 01:23:51PM -0400, Robert Watson wrote:
    > > The other concern I have is whether the message queues get deep or not:
    > > many of the benefits of message queues come when the queues allow
    > > coallescing of context switches to process multiple packets. If you're
    > > paying a context switch per packet passing through the stack each time you
    > > cross a boundary, there's a non-trivial operational cost to that.
    >
    > I don't know what Matt has done here, but at least with the design we
    > used for G2 (a private DFly-like project that John Dyson, I, and a few
    > other people I don't know if want to be anonymous or not ran), this
    > should not an issue. We used thread context passing with an API that
    > contained putmsg_and_terminate() and message ports that automatically
    > could spawn new handler threads. Effectively, a message-related context
    > switch turned into "assemble everything I care about in a small package,
    > reset the stack pointer, and go". The expectation was that this should
    > end up with less overhead than function calls, as we could drop the call
    > frames for "higher levels in the chain". We never got to the point
    > where we could measure if it worked out that way in practice, though.

    Sounds a lot like a lot of the Mach IPC optimizations, including their use
    of continuations during IPC to avoid a full context switch.

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Senior Research Scientist, McAfee Research

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Daniel Eischen: "Re: atomic reference counting primatives."

    Relevant Pages

    • Re: learning asm.
      ... context switch is required but that a CALL - sans context switch, ... As for context switches and user -> supervisor transitions, ... Yes, sort of... ...
      (alt.lang.asm)
    • Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
      ... context switches. ... and add the data to the buffer. ... The generic OProfile code defines a mutex lock, called buffer_mutex, to ... Thus we were not able to pass the context switch data as ...
      (Linux-Kernel)
    • Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
      ... context switches. ... and add the data to the buffer. ... not have any built in functions for handling the SPU. ... It is important that the data get context switch data get recorded as ...
      (Linux-Kernel)
    • Re: Concurrent Sequential
      ... It was the context switch problem that caused us to look for an alternate ... The PID contains a pointer to the private stack. ... some "flag" is set to signal completion of the I/O ...
      (comp.arch)
    • Re: Memory barriers, drivers, and interrupts
      ... context from affecting another context which has nothing to do with the ... memory barrier on the context switch so memory accesses don't occur ... the pipeline so all memory accesses complete before the context switch ... the idea of a context switch doesn't solve the memory barrier ...
      (comp.programming.threads)