From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <240f5378b5581b3d40cce5043307530d@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Threads: Sewing badges of honor onto a Kernel In-Reply-To: <20040228105025.1a94f714.martin@parvat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 28 Feb 2004 08:41:09 -0500 Topicbox-Message-UUID: 02001b6c-eacd-11e9-9e20-41e7f4b1d025 The overhead on fork/exec of having to copy the stack descriptors into the forked process is pretty minimal compared to the exec. If you are just forking without execing then getting a new stack is what you want. If you are forking and sharing memory twixt the two forked processes, we do indeed take a hit every time the processes context switch especially on the x86 where we lose the previous tlb context as soon as we putcr3(). If the two processes shared the TLB state (pid on mips, page table on x86) we'ld be able to avoid that. Not having any private segments would allow us to do it. If you are serious about caring, throw another bit into rfork that says dump the stack segment. You'll also have to find someplace in all architectures to hide the pointer to the thread private memory. Add to the kernel support for sharing the TLB state. Then measure the two and tell us how much you saved in various programs. If its non-neglibigle, you'll have a reason argument instead of this endless whining back and forth.