From owner-freebsd-current Fri Feb 19 18:56:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id CC57510E7A for ; Fri, 19 Feb 1999 18:56:51 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA24875; Fri, 19 Feb 1999 19:56:50 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd024824; Fri Feb 19 19:56:39 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id TAA24109; Fri, 19 Feb 1999 19:56:34 -0700 (MST) From: Terry Lambert Message-Id: <199902200256.TAA24109@usr02.primenet.com> Subject: Re: SMP and SO5.0 To: dyson@iquest.net Date: Sat, 20 Feb 1999 02:56:32 +0000 (GMT) Cc: julian@whistle.com, luoqi@watermarkgroup.com, current@FreeBSD.ORG In-Reply-To: <199902171940.OAA69973@y.dyson.net> from "John S. Dyson" at Feb 17, 99 02:40:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > You may try my patch at http://www.freebsd.org/~luoqi, which would allow > > > linux threads to run on SMP. > > > > I've gone through these patches and I can see that they are really needed > > for SMP where address spaces are shared. > > I agree -- a per-cpu page directory per multithreaded process is the way that > I had implemented. Excellent!!! Ugh. I'm sorry, but this is just evil(tm). The kernel stack and the process address space reference need to be divorced from the traditional concept of "process" (and point back at the process). As such, the sleep and scheduling is done by the context, not the process. These contexts could then be used either as thread contexts (bad idea) or async call contexts (good idea). This solves the seperation problem, the process ID problem, the thread identification problem, the thread grouping problem, the N:M mapping problem, the "quantum churning" problem, the kernel preemption problem, and the threads kernel stack overflow problem. This also resolves the "pessimal scheduling for concurrent threads on an SMP system" problem. Ideally, a thread is still a user space construct, and all call conversion scheduler in user space is used, as well as placing the POSIX AIO stuff in a library. Protection domain crossing costs are next to NIL, given that the unified VM and buffer cache get rid of the bmap costs. Oh yeah. This also solves the hybrization problem, which Solaris solves by running an extra thread for spawning new threads. Comments? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message