Date: Tue, 13 Nov 2001 17:04:18 -0500 From: Daniel Eischen <deischen@gdeb.com> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Thread scheduling in the kernel Message-ID: <3BF198E2.24EE658F@gdeb.com> References: <Pine.BSF.4.21.0111130929230.98845-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). -- Dan Eischen 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?3BF198E2.24EE658F>