Date: Mon, 29 Nov 1999 09:11:13 -0700 From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: Jason Evans <jasone@canonware.com>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911291611.JAA19058@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9911250109290.12692-100000@current1.whistle.com> References: <19991124220406.X301@sturm.canonware.com> <Pine.BSF.4.10.9911250109290.12692-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > This sounds similar to Solaris LWPs in that there are potentially KSEs > > blocked in the kernel, whereas with scheduler activations (SA), that > > doesn't happen under normal circumstances. > > No, under SA KSE's block. and another KSE is generated to act as a > replacement. it is used to run the activation that is passed to the > scheduler, and this the next thread the process runs. That's not how I read the paper. I think we all might be on the 'same page', but I think we're all using different terminology. How's about we define what a KSE is, a SA is, and come up with some other term for a userland 'thread'? It seems that Julian is using the same term for a userland thread and a context that can go into the userland as a KSE, but I'm not sure. Assuming for a moment that this is the case, then is a SA a 'kernel context' that wraps up a KSE when it goes 'live' (the UTS schedules it)? If so, then the KSE and the SA are essentially the same thing, aren't they? > there must be. > there is a stack that must be saved, and registers. this is a KSE. > > > The syscall context has some kernel context, but there is no bonifide > > context, such as with Solaris's LWP model. When the syscall completes, a > > new activation is created for the upcall to the UTS. > > A KSE is basicaly saved proocessor state, including a stack, and some > linkage points to allow that to be hug of various other structures, e.g. > sleep queues, procs , subprocs, etc. How does the UTS allow another thread to use this 'KSE' when *IT* decides to allow another user0land thread to run? As I read the SA paper, this is how things are done. > > That said, I disagree with the idea of the UTS having explicit control over > > scheduling of KSEs. Hmm.... I think that there should be exactly one KSE per > > processor (with the exception of PTHREAD_SCOPE_SYSTEM (bound) threads), and > > that threads should be multiplexed onto the KSEs. This lets the kernel > > schedule KSEs as it sees fit, and lets the UTS divide the runtime of the > > KSEs as it sees fit. How does the UTS 'divide' the runtime if it isn't allowed to schedule the KSE? What is the difference between 'schedule' and 'divide'? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911291611.JAA19058>