Date: Tue, 23 Nov 1999 16:22:22 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Jason Evans <jasone@canonware.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <383B058E.694FDE4C@vigrid.com> References: <Pine.BSF.4.10.9911230034540.20163-100000@picnic.mat.net> <Pine.SUN.3.91.991123070425.5418A-100000@pcnet1.pcnet.com> <19991123113106.G301@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote: > > I think the sleep queues need to be KSEs, and perhaps someday they'll > > become per-mutex or condvar queues :-). I think the run queue has to > > remain process (or kernel thread) oriented. The KSE run-list would be > > hung off each process. > > How do you see this working with KSE soft processor affinity? It seems to > me that there would be difficulty in determining which of a set of KSEs > associated with a process should be run on a given CPU, if the run queue is > at the process granularity. I guess it depends on how you look at it. If a threaded application is granted multiple (sub)processes in order to run on multiple CPUs, you can view each subprocess as a vessel in which the UTS schedules work. The UTS knows how many subprocesses it has and can try to keep both supplied with threads. The UTS can also try to keep threads on the same process as they last executed. The kernel can do this also by keeping per-subprocess lists of KSEs, but this is only for KSEs that block/unblock in the kernel. It doesn't know about other threads that are scheduled on the subprocess by the UTS. I guess it might be OK to keep KSE lists hung off each subprocess, but what we want to ensure is that if a thread is preempted on one subprocess, the next cooperating subprocess is informed of the event. This is to ensure that if it is in a critical region, it can be resumed until it exits the critical region. Now what if we want a subprocess with "other than default" priority that only runs a small group of threads? Only the UTS knows what threads should be scheduled on this subprocess. We also don't want to use this subprocess as a vessel for other work because we want to reserve its quantum for the truly important events that may occur. In this situation, it makes a lot of sense to have the blocked/unblocked KSE list hung off the subprocess; as soon as there is an unblocked KSE on the subprocess, it is added to the run queue and can be scheduled at its other-than-default priority. 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?383B058E.694FDE4C>