Date: Sun, 12 Dec 1999 14:13:04 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Arun Sharma <adsharma@sharmas.dhs.org> Cc: arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <3853F3C0.EE96FB16@vigrid.com> References: <Pine.BSF.4.10.9912112354520.26823-100000@current1.whistle.com> <38539C2B.9632089A@vigrid.com> <19991212095553.A7995@sharmas.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Arun Sharma wrote: > > On Sun, Dec 12, 1999 at 07:59:23AM -0500, Daniel M. Eischen wrote: > > > A lot of time was spent discussing the mechanisms by which the UTS > > > received upcalls and how KSE's would resume. It was agreed that > > > thread classes could be implemented by a structure half way between a > > > process and a KSE on the linkage scale of things, that would own KSEs > > > and which would be scheduled onto processors. This basically corresponds > > > to what I've been calling a "subproc". In our diagrams it was designapted > > > "Q" as P was already taken (for Proc). This was actually an apt name as > > > this structure si what is put in the run queue. It was also agreed that to > > > start off this would be a virtual structure an it would be part of the > > > "proc" struct for the first revisions. > > > > Wouldn't this be akin to what other systems call a kernel thread or LWP? > > A kernel thread or a LWP has a 1-to-1 relationship with a kernel stack. > In our discussion, a KSE has a 1-to-1 relationship with a kernel stack. The > purpose of the Q structure was to enforce "scheduling classes" - to > represent a set of threads having the same priority and to ensure > fairness in the scheduler. > > Apart from this distinction, KSE is the closest to a kernel thread/LWP > and could possibly be used to implement blocking interrupt threads. A KSE can't be placed in the run queue (or isn't in our implementation). A LWP or kernel thread can be. A LWP can have it's own priority. I'd argue that our Q much closer resembles a LWP than does a KSE. > It was also agreed that it doesn't make sense to do everything at once, > but do it in some sensible order, without precluding elements of the > design. Some of the tasks - break the proc structure into a proc and KSE, > per CPU scheduling queues, implementing SA. > > My personal opinion is that it might be easier to go in steps - > rfork/clone based implementation (aka linuxthreads), then a Solaris like > m x n implementation and then scheduler activations. Implementation wise, > they're in the increasing order of difficulty. From what I heard from > Terry, this is also the path that Solaris took. This also lets application > writers pick the right model for their work. I dunno. It seems easier to me to implement SA from the start, concentrating on eliminating much of the extraneous code in libc_r. I'd start with making it only work for one process or Q. The userland part of this seems really easy to me. Once that works, I'd add the ability to have multiple Q's. > If we stick to the POSIX threads interface strictly, we shouldn't be > afraid of getting stuck with one of the implementations. > > Other concerns that were expressed - crossing protection boundaries too > often to pass messages about blocking and rescheduling. Matt Dillon > responded that these messages could be batched and made more efficient. I agree. It seemed like the SA paper went to extremes in notifying the UTS of unblocked threads. I think we can do this at more opportune times, like when a Q is resumed or on a user->kernel crossing. I don't know that we want to be interrupting a Q while it is running a thread just to notify the UTS that another thread has unblocked in the kernel. Dan Eischen eischen@vigrid.com 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?3853F3C0.EE96FB16>