Date: Fri, 08 Jun 2001 00:33:36 -0400 From: Jake Burkholder <jburkholder0829@home.com> To: jwm@CSUA.Berkeley.EDU Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Information on context stealing Message-ID: <20010608043337.105CC22A5@k7.rchrd1.on.wave.home.com> In-Reply-To: Message from John Milford <jwm@CSUA.Berkeley.EDU> of "Thu, 07 Jun 2001 20:16:17 PDT." <200106080316.f583GHP35188@soda.csua.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have some free time coming up soon, and I am interested in > working on context stealing for FreeBSD. However in begining to look > into it, I have run up against some questions I have not been able to > answer from the web page or email archives. > > 1) It the purpose solely to reduce process overhead, are these > threads also to be created on demand, or are there other > objectives as well such as reduced memory overhead? The purpose is solely to reduce the overhead required to context switch from a process to an interrupt thread. > 2) Since KVM is mapped into every process, would it meet the > goals to preform a full context switch to one of these > lightweight threads, except that cr3 is not touched? More or less. This is one of the goals, another would be to not save the floating point state if the current process is using it, to generally stream line the whole code path. Its also conceivable to not switch the stack pointer, but I don't know why anyone in their right mind would do this. > > It would be really helpful if someone could point me in the direction > of a document that could clarify these for me. Also if someone has > already thought through some or all of this and has soe notes that > would be helpful as well. I am assuming that no one has started > becasue the project has a not started status on the web page. Thank > you for any help/clarification you can offer. The documentation that I know about is the BSD/OS source code which implements this to some extent, as well as a general SMPng goals and definitions document. Unfortunately this stuff is the property of BSDi and/or wind river, so its currently only available to committers and employees. I've studied the code in question extensively and I started implementing it for FreeBSD, but I never finished. I decided that there was more to be gained with less effort by working on adding data locking to the kernel to push down the giant mutex and working on other areas of the scheduler. Also, I feel that any implementation that is truly light weight will be very complex and have subtle implications, to the point that few people other than the implementer will understand it or be able to maintain it. I believe that the BSD/OS code suffers from this. In any case, what I've done is on my web page: http://people.freebsd.org/~jake/ithd.diff its rather old and stale. I wrote a kld that tested the blocking and non-blocking cases but I can't seem to find it. I never ran this code with real interrupts. I don't mean to scare you away, but a lot of people seem to want this and I don't think they have fully considered the ramifications beyond the buzzwords. Let me know if you have any questions. Jake > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010608043337.105CC22A5>