Re: Network Stack Locking

From: Alan Cox (alc_at_cs.rice.edu)
Date: 05/25/04

  • Next message: Matthew Dillon: "Re: Network Stack Locking" 
    Date: Tue, 25 May 2004 01:54:10 -0500
To: dillon@backplane.com, arch@freebsd.org

    >: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
    >
    > Well, I like the performance aspects of a continuation mechanism, but
    > I really dislike the memory overhead. Even a minimal stack is
    > expensive when you multiply it by potentially hundreds of thousands
    > of 'blocking' entities such as PCBs.. say, a TCP output stream.
    > Because of this the overhead and cache pollution generated by the
    > continuation mechanism increases as system load increases rather
    > then decreases.

    When the explicit continuation mechanism was used, the thread's stack
    was freed when the thread blocked and a new stack allocated when the
    thread was restarted. Here is a URL:
    http://citeseer.ist.psu.edu/draves91using.html. Notice the mention of
    space reduction in the abstract. It's worth reading.

    Alan

    _______________________________________________
    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: Matthew Dillon: "Re: Network Stack Locking"

    Relevant Pages