Date: Mon, 2 Dec 1996 12:33:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@whistle.com (Julian Elischer) Cc: cracauer@wavehh.hanse.de, nawaz921@cs.uidaho.EDU, freebsd-hackers@freebsd.org Subject: Re: clone()/rfork()/threads (Re: Inferno for FreeBSD) Message-ID: <199612021933.MAA11060@phaeton.artisoft.com> In-Reply-To: <32A27CB2.59E2B600@whistle.com> from "Julian Elischer" at Dec 1, 96 10:52:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The additonal options are needed to produce a Posix-compatible thread > > interface that has no userlevel threads anymore. Linus claims Linux > > syscalls are fast enough to be acceptable even in applications with > > heavy use of locking (and therefore resheduling by the kernel). > > He might be correct. > sharing memory spaces makes for a much smaller contect switch. Assuming you switch from one context in a thread group to another. In which case, it is possible for a threaded process to starve all other processes, depending on if its resource requests are satisfied before all the remaining threads in the thread group have also made blocking requests (otherwise, you are not prioritizing by being in the thread group, and there are virtually no contex switch overhead wins from doing the threading -- only the win that a single process can compete for N quantums instead of 1 quantum when there are N kernel threads in the thread group). A good thread scheduler requires async system calls (not just I/O) and conversion of blocking calls to non-blocking calls plus a context switch in user space (quasi-cooperative scheduling, like SunOS 4.1.3 liblwp). This would result in a kernel thread consuming its full quantum, potentially on several threads, before going on. One of the consequences of this is that sleep intervals below the quantum interval, which will work now, without a high degree of reliability, will now be guaranteed to *not* work at all. Timing on most X games using a select() with a timeout to run background processing, for instance, will fail on systems that use this, unless a kernel preempt (a "real time" interrupt) is generated as a result of time expiration, causing the select()-held process to run at the time the event occurs, instead of simply scheduling the process to run. This leads to buzz loop starvation unless you limit the number of times in an interval that you allow a process to preeempt (ie: drop virtual priority on a process each time it preempts this way, and rest on quantum interval). >From my reading of the Linux scheduler code, they are about the crudity stage of the SVR4 processes -- ie: no real advantage in context switching unless the threaded process is run on an otherwise quiescent machine. > Once teh kernel stacks are not in the user space > (they might already be gone by now I haven't looked.. SMP needs it too > I think) then the way is clear for this... Topologically, kernel preemption and SMP are quite similar. The only real difference is that SMP requires mutex'es to cross memory synchronization domains, whereas kernel preemption (for RT scheduling and/or RT timer events) only requires semaphores (on a UP system). It's all a matter of scheduling granularity, and deciding what context can and can't be lazy-bound. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612021933.MAA11060>