Date: Thu, 16 Nov 2000 23:23:58 -0500 From: Garrett Rooney <rooneg@electricjellyfish.net> To: Alfred Perlstein <bright@wintelcom.net>, frank xu <bsdman@hotmail.com>, arch@freebsd.org Cc: arch@FreeBSD.ORG Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <20001116232358.A25846@electricjellyfish.net> In-Reply-To: <20001116184200.L18037@fw.wintelcom.net>; from Alfred Perlstein on Thu, Nov 16, 2000 at 06:42:01PM -0800 References: <F99h9vXsFFsAitVGeSJ000001f0@hotmail.com> <20001116184200.L18037@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 16, 2000 at 06:42:01PM -0800, Alfred Perlstein wrote: > * frank xu <bsdman@hotmail.com> [001116 18:25] wrote: > > I have readed an article about KSE from jasone, it's cool, can complete > > resolve much headache, but you method has same problems as LinuxThread, > > jasone already > > talked about it, in new FreeBSD 5.0, why can't we have a new way to go? > > Actually KSE is closer to Linuxthreads than my suggestion from my > point of view. Can you elaborate a bit? well, i don't know if you've come up with a way around this, but in the KSE paper (avail. from http://www.freebsd.org/~jasone/kse) the problems with using rfork() based threads for spreading threads across processors runs into the following issues: 1) each thread is a separate process, and such has a unique pid. POSIX requires each thread to appear to have the same pid, so substantial modifications to the kernel data structures would be required. 2) thread priority semantics specified by POSIX cannot be implimented because each thread is a a process. thread contention at the application level is therefor not possible, all threads are scheduled as processes. this lets multithreaded applications compete unfairly with single threaded applications. 3) Thread switching becomes expensive, because it is a full context switch, requiring dropping into the kernel, switching one proc out, and the other in. the only way to fix this is to optimize process switching, which gets hard past a certain point. 4) each thread has all the kernel resources associated with a process, so applications with many threads require a lot of kernel resources. all of these problems are basically cribbed right out of the paper, all the mistakes are mine, not his. -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001116232358.A25846>