Date: Tue, 23 Nov 1999 07:19:54 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Chuck Robey <chuckr@picnic.mat.net> Cc: Julian Elischer <julian@whistle.com>, Nate Williams <nate@mt.sri.com>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads Message-ID: <Pine.SUN.3.91.991123070425.5418A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.10.9911230034540.20163-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Nov 1999, Chuck Robey wrote: > It seems to me that we're talking about, basically, changing the scheduler > from being process-centric to being KSE-centric, right? I think that > means that, excepting possible per-process limits, the scheduler wouldn't > care what process was up, and it would be keeping KSE run-lists, > wait-lists, etc, right? 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. > I'm wondering if there might possibly be some way to preserve some level > of simplicity by keeping ksid'd like we keep pid's now, so that things > that juggle a 32 bit entity keep on doing that, although perhaps under > another name. I think you're basically right in keeping things simple. I think that a non-MT process should be equivalent to a MT process. The non-MT process has only one co-operating process (itself) and one KSE. Whenever the non-MT process blocks in the kernel, there are no more available KSEs, so another process is scheduled. 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?Pine.SUN.3.91.991123070425.5418A-100000>