Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!www.nntp.primenet.com!nntp.primenet.com!news.iquest.net!not-for-mail From: "John S. Dyson" <dyson@freebsd.org> Newsgroups: comp.programming.threads,comp.unix.bsd.freebsd.misc Subject: Re: [??] pure kernel vs. dual concurrency implementations Date: Tue, 25 Feb 1997 13:00:52 -0500 Organization: John S. Dyson's home machine Lines: 31 Message-ID: <331328D4.41C67EA6@freebsd.org> References: <330CE6A4.63B0@cet.co.jp> <5etasa$blt@news.cc.utah.edu> <5etous$j0l@flea.best.net> NNTP-Posting-Host: dyson.iquest.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) Xref: euryale.cc.adfa.oz.au comp.programming.threads:3307 comp.unix.bsd.freebsd.misc:36103 Matt Dillon wrote: > > What I haven't tested is the best-case context switch overhead > that occurs when the MMU needs to be given a new VM context. This > does NOT apply to thread switching, however, unless you use a > braindead 'must VM context switch the kernel stack because, gee, > my fork code overlays the individual kstacks for the threads under > any given process at the same address' approach... a very stupid > approach, if you ask me. I've written several OS's (for turnkey 680x0 > single board computers) that can switch user threads through a supervisor > interrupt VERY quickly... on the order of 10uS on a 20 MIPS 680x0 cpu. > We still have the problem of the kernel stack being at a fixed VA. I think that NetBSD has fixed that problem, and one of the first steps in adding kernel-based threads will be to allow the kernel stack to be at an allocated KVA. Also, we will allow the UPAGES to be either relocatable (or the persistant part of the UPAGES will be merged with the proc data structure.) At that point, we will be able to fully share address spaces with only a reference count on the vmspace data structure. There are other ways of sharing the address space (with a few mods) in our VM system, but I believe that the overhead will be less with the proposed vmspace sharing. For context switches from thread to thread, we'll make sure that we won't flush the TLB, etc. That should help a bit also. John dyson@freebsd.org