Date: Thu, 16 Nov 2000 20:34:28 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Garrett Rooney <rooneg@electricjellyfish.net> Cc: frank xu <bsdman@hotmail.com>, arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <20001116203428.M18037@fw.wintelcom.net> In-Reply-To: <20001116232358.A25846@electricjellyfish.net>; from rooneg@electricjellyfish.net on Thu, Nov 16, 2000 at 11:23:58PM -0500 References: <F99h9vXsFFsAitVGeSJ000001f0@hotmail.com> <20001116184200.L18037@fw.wintelcom.net> <20001116232358.A25846@electricjellyfish.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Garrett Rooney <rooneg@electricjellyfish.net> [001116 20:23] wrote: > 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. Yes, there are all problems in Linuxthreads, but not KSE nor my idea. Honestly my idea has more than several flaws, including things like blocking during open() and close()* (*over NFS) when accessing files. It's just that things like mysql and most threaded applications might benifit over the near trivial implementation of aio_/SIGPNP/sysVpoll almost as much as KSE. I really don't want to get into a big discussion about this. I had no intention of discrediting KSE project, the idea was that someone with some kernel programming skill and a couple of free weekends could improve on the uthread system while Jason continued on his quest for KSE. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20001116203428.M18037>