From owner-freebsd-smp Sun Feb 18 0:15:46 2001 Delivered-To: freebsd-smp@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 2A25C37B491 for ; Sun, 18 Feb 2001 00:15:39 -0800 (PST) Received: (qmail 20969 invoked by uid 666); 18 Feb 2001 08:27:37 -0000 Received: from i003-020.nv.iinet.net.au (HELO elischer.org) (203.59.3.20) by mail.m.iinet.net.au with SMTP; 18 Feb 2001 08:27:37 -0000 Message-ID: <3A8F8495.F7313ECD@elischer.org> Date: Sun, 18 Feb 2001 00:15:17 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Seth Leigh Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Well I read the stuff, and I get it now. References: <5.0.2.1.0.20010218021929.00aaef98@hobbiton.shire.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Seth Leigh wrote: > > > Actually, I just thought of how it could be done while re-reading my post > prior to sending it off. Is this what you guys have thought of too? The > idea is that since the kernel is already getting interupted 100 times per > second (or however many times FreeBSD does it) anyhow, the running > scheduler activation is *already* going to be preempted off the cpu for the > duration of that tick processing. So, after the tick processing is done > and the kernel dispatcher decides that this particular scheduling > activation may continue running as it was doing before the timer interupt > fired, rather than simply context switch back into that particular > scheduler activation, the kernel would use a *second* scheduler activation > and upcall into the threads library's scheduler. This would basically > allow the threads library's scheduler to "piggyback" onto the kernel's > scheduler, without requiring anymore crossings of the protection boundaries > than were going to be had anyhow. Basically, this scheme would use twice > as many scheduler activations as it wanted to really have be run, basically > using half of them to call up into the threads library after each tick to > decide whether to keep running the preempted thread or scheduler a > different one. > > What do you all think? Or is this already the plan? kind-of.. Basically all returns from the kernel to the user process might go first via the UTS (Userland Thread Scheduler). This includes page faults and interrupts of some types. We have not completely decided how many and which. In addition, timer signals can be delivered after clock interrupts as well. THe current code uses timer signals, but upcalls are almost the same thing. The saved state of the thread (when a timer interrupt completes and retunr is sent back to the UTS) is made to b ecompatible with all stopped threads so that the interrupted thread looks like all the other runnable threads, and the UTS can simply decide which to restart. > > Seth > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message