Date: Tue, 13 Nov 2001 14:22:51 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Daniel Eischen <deischen@gdeb.com> Cc: arch@FreeBSD.ORG, Julian Elischer <julian@elischer.org> Subject: Re: Thread scheduling in the kernel Message-ID: <XFMail.011113142251.jhb@FreeBSD.org> In-Reply-To: <3BF198E2.24EE658F@gdeb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13-Nov-01 Daniel Eischen wrote: > Julian Elischer wrote: >> >> (I notice you only comented on the first half, but that's a lot better >> than the complete lack of interest from everyone else.....) >> >> On Mon, 12 Nov 2001, John Baldwin wrote: >> >> > >> > On 12-Nov-01 Julian Elischer wrote: >> > > >> > > In an attempt to get the next part of the KSE work designed (design >> > > before >> > > code you know.. a strange new concept) I've been trying to work out >> > > the "correct" scheduling methods for such a system. >> > > >> > > There are a few 'tricks' that need to be taken into account.. >> > > >> > > a few notes.. >> > > >> > > >> > > 1/ Since threads running a syscall hit 'sleep' events >> > > the entities on teh sleep queues must be the threads. >> > > >> > > 2/ the entity that is scheduled onto the run queues is the KSE. >> > > (as the name suggests). >> > > >> > > 3/ If we have only one run queue, then KSEs for several processors >> > > from the same process, may be on the same queue. >> > > >> > > 4/ If threads 'wake up' they are hung of a list of runnable threads >> > > somewhere. This list could be hanging off the process, or the KSE. >> > > (actually more likely the KSEgroup than the process but...) >> > >> > It should hang off the group. >> >> This was my original idea. However I ended up splitting that queue up so >> that it was on each KSE and allowed a KSE with no work to steal work from >> another. i.e. a virtual single queue, with KSE affinity. If I bind KSEs to >> processors lightly, then I bind threads at the same time. (lightly) >> >> The idea is that threads are put on the queue for the KSE on which they >> last ran. Only when a KSE runs out of runnable threads on its own list and >> still has teh CPU, will it try steal work from another in the same group. >> >> The downside is that there is no overall priority between threads in a >> group.. This is one thing I want o discuss... the queueing model. > > I just want to make a couple comments without getting too involved > in how the kernel deals with threads, KSEs, and KSE groups. > > I think that at first there will probably be only 1 UTS run > queue per KSE group. This probably means that the UTS will > also hang blocked threads off its version of the KSE group. I > guess in this case, unblock events from the kernel can be sent > to any KSE within the group. But if the UTS wants to have a > run queue for each KSE, then the kernel should only be handling > the blocking and unblocking of threads within the same KSE > in which the thread originally entered the kernel. > > I think the UTS will only set priorities for the KSE group. It > doesn't make sense to me for the (application visible) priority > to be anywhere other than the KSE group. If the kernel needs > to temporarily play with priorities for its own purposes (inheriting > priority when holding a mutex), then each thread probably needs > an active priority which is MAX(kse->inherited, kseg->prio). What about the priorities passed in to condition variables and msleep/tsleep? That is why I think Julian wanted per-thread priorities. Also, the priority propagation priority is _defintiely_ a thread and not a KSE property, since the thread owns teh lock that has the assoiated priority, not the KSE. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.011113142251.jhb>