Date: Sun, 18 May 1997 23:45:28 -0400 From: "David S. Miller" <davem@caip.rutgers.edu> To: dyson@FreeBSD.ORG Cc: terry@lambert.org, deischen@iworks.InterWorks.org, freebsd-hackers@FreeBSD.ORG, jb@freebsd1.cimlogic.com.au Subject: Re: GNAT-pthreads integration bugs/questions Message-ID: <199705190345.XAA16247@darkwing.rutgers.edu> In-Reply-To: <199705190330.WAA10372@dyson.iquest.net> (toor@dyson.iquest.net)
next in thread | previous in thread | raw e-mail | index | archive | help
From: "John S. Dyson" <toor@dyson.iquest.net> Date: Sun, 18 May 1997 22:30:02 -0500 (EST) Why does rfork need to be concerned with a stack? It can be handled in userland. What I meant was that (in userspace) the per instance of execution (however it is defined in this rfork model) can use it's stack as a place to acquire "thread local data" sort to speak, and that it could possibly be applied to this person's problem. For a real keen application of this technique, I refer people to the SMP Digital UNIX paper mentioned here a week or two ago. We use that technique hevaily in the Linux kernel on just about every architecture now. There is no global "current process structure" in the kernel address space any more, because it can be fabricated by: current_task = (stack_pointer & ~((PAGE_SIZE*2)-1)); (On the Intel and Alpha, the hardware loads the supervisor stack pointer for you at trap time, wheee process struct is just there, zero cost) This also obviates any special cases for SMP, this might help to tone down the 6,000 SMP cross calls per second I see FreeBSD SMP performing, actually this would only be a chisel to that problem. Most of the time, Linux performs close to none at all. Changing the kernel address space for anything is bad news on SMP, I don't care what kind of optimizations you put into the SMP tlb flushing code in a kernel that does VM based VFS operations (and yes I am intimately familiar with all the gross hacks SVR4 etc. put into their code to try and fight this problem, it just doesn't work), it will never perform adequately. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705190345.XAA16247>