Date: Tue, 23 Nov 1999 11:31:06 -0800 From: Jason Evans <jasone@canonware.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991123113106.G301@sturm.canonware.com> In-Reply-To: <Pine.SUN.3.91.991123070425.5418A-100000@pcnet1.pcnet.com>; from eischen@vigrid.com on Tue, Nov 23, 1999 at 07:19:54AM -0500 References: <Pine.BSF.4.10.9911230034540.20163-100000@picnic.mat.net> <Pine.SUN.3.91.991123070425.5418A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 23, 1999 at 07:19:54AM -0500, Daniel Eischen wrote: > 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. 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. Jason 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?19991123113106.G301>