Date: Tue, 13 Nov 2001 17:46:08 -0500 From: Daniel Eischen <deischen@gdeb.com> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org, Julian Elischer <julian@elischer.org> Subject: Re: Thread scheduling in the kernel Message-ID: <3BF1A2B0.A0BC7469@gdeb.com> References: <XFMail.011113142251.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
>
> 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).
^^^ s/kse/thread
Sorry, I meant thread above, not kse.
> What about the priorities passed in to condition variables and msleep/tsleep?
The KSE group has the base priority from which all member threads
inherit. The active priority is stored in each thread and is the
maximum of the KSE groups (base) priority and any priority that the
thread inherits from synchronization objects.
> 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.
Yep, sorry I did mean thread above, not KSE.
--
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?3BF1A2B0.A0BC7469>