Re: Network Stack Locking
From: Alan Cox (alc_at_cs.rice.edu)
Date: 05/25/04
- Previous message: Robert Watson: "Re: Network Stack Locking"
- Maybe in reply to: Robert Watson: "Network Stack Locking"
- Next in thread: Matthew Dillon: "Re: Network Stack Locking"
- Reply: Matthew Dillon: "Re: Network Stack Locking"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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"
- Previous message: Robert Watson: "Re: Network Stack Locking"
- Maybe in reply to: Robert Watson: "Network Stack Locking"
- Next in thread: Matthew Dillon: "Re: Network Stack Locking"
- Reply: Matthew Dillon: "Re: Network Stack Locking"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
