Date: Mon, 20 Nov 2000 17:39:06 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Terry Lambert <tlambert@primenet.com> Cc: Scott Hess <scott@avantgo.com>, Julian Elischer <julian@elischer.org>, jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <Pine.SUN.3.91.1001120173334.1280B-100000@pcnet1.pcnet.com> In-Reply-To: <200011202156.OAA02067@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Nov 2000, Terry Lambert wrote: > > I have seen the notion of limiting KSE's to the number of CPUs mentioned a > > number of times on the arch and smp lists. This is presumably done to > > maximize performance of CPU-bound and network-I/O-bound programs. > > A KSE is a "reservation for quantum". It is effectively a quantum > holder. The quantum can be spread against multiple threads in user > space. Except on multiple CPUs, which would permit multiple KSEs, > all CPU utilization is serialized through the scheduler anyway. This isn't what has been defined. The KSEG is the "reservation for quantum", but I do tend to agree that it should in fact be the KSE. > > On Mon, 20 Nov 2000, Julian Elischer wrote: > > > A KSEG can only have as a maximum N KSEs associated with it, where N is > > > the number of processors, (unless artificially reduced by a lower > > > concurency declaration). (you said this but only indirectly). In > > > general, KSEs are each assigned to a processor. They do not in general > > > move between processors unless some explicit adjustment is being > > > made(*), and as a general rule, two KSEs will not be assigned to the > > > same processor. (in some transitional moments this may be allowed to > > > briefly happen) This in general if you run a KSEC on the same KSE it was > > > run on last time, you should be on the same processor, > > > (and get any affinity advantages that might exist). > > I really, really disagree with Julian's statement about not > assigning multiple KSEs to the same processor. There are > perfectly valid loading reasons (e.g. two KSEs that each take > 30% of the CPU, cooperating, with one CPU with a process that > takse 90% of the CPU, while the other CPU is only at 60% > utilization, etc.). > > There is also the PTHREAD_SCOPE_SYSTEM scheduling; one can > easily conceive of a multithreading application, where one thread > in the total list of threads needs to run with a real time > priority to insure rapid interacative response, with metered > intervals. One example would be a DVD player, where the > rendering needs to occur at fixed intervals with no latency, > whereas the fuffer-refill from the DVDROM, and the control > functons for the program, overall, can run in normal priority > threads. We have an application that has very similar needs. Right now we use Solaris, with some threads in RT and some not in RT. I intend on making this work in FreeBSD also. -- 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?Pine.SUN.3.91.1001120173334.1280B-100000>