Date: Sun, 12 Dec 1999 09:55:53 -0800 From: Arun Sharma <adsharma@sharmas.dhs.org> To: arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <19991212095553.A7995@sharmas.dhs.org> In-Reply-To: <38539C2B.9632089A@vigrid.com>; from Daniel M. Eischen on Sun, Dec 12, 1999 at 07:59:23AM -0500 References: <Pine.BSF.4.10.9912112354520.26823-100000@current1.whistle.com> <38539C2B.9632089A@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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. -Arun 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?19991212095553.A7995>