From owner-freebsd-hackers Sun May 18 20:48:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA00636 for hackers-outgoing; Sun, 18 May 1997 20:48:23 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA00630; Sun, 18 May 1997 20:48:19 -0700 (PDT) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.155.100]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id UAA20365; Sun, 18 May 1997 20:48:13 -0700 (PDT) Received: from darkwing.rutgers.edu (darkwing.rutgers.edu [128.6.111.4]) by caipfs.rutgers.edu (8.8.5/8.8.5) with ESMTP id XAA05807; Sun, 18 May 1997 23:45:41 -0400 (EDT) Received: (davem@localhost) by darkwing.rutgers.edu (8.8.4/8.6.9) id XAA16247; Sun, 18 May 1997 23:45:28 -0400 Date: Sun, 18 May 1997 23:45:28 -0400 Message-Id: <199705190345.XAA16247@darkwing.rutgers.edu> From: "David S. Miller" To: dyson@FreeBSD.ORG CC: terry@lambert.org, deischen@iworks.InterWorks.org, freebsd-hackers@FreeBSD.ORG, jb@freebsd1.cimlogic.com.au In-reply-to: <199705190330.WAA10372@dyson.iquest.net> (toor@dyson.iquest.net) Subject: Re: GNAT-pthreads integration bugs/questions Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: "John S. Dyson" 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 /_____________/ / // /_/ ><