Date: Sun, 18 Feb 2001 00:15:17 -0800 From: Julian Elischer <julian@elischer.org> To: Seth Leigh <seth@pengar.com> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Well I read the stuff, and I get it now. Message-ID: <3A8F8495.F7313ECD@elischer.org> References: <5.0.2.1.0.20010218021929.00aaef98@hobbiton.shire.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A8F8495.F7313ECD>