Date: Sat, 20 Feb 1999 02:56:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@iquest.net Cc: julian@whistle.com, luoqi@watermarkgroup.com, current@FreeBSD.ORG Subject: Re: SMP and SO5.0 Message-ID: <199902200256.TAA24109@usr02.primenet.com> In-Reply-To: <199902171940.OAA69973@y.dyson.net> from "John S. Dyson" at Feb 17, 99 02:40:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902200256.TAA24109>