From owner-freebsd-arch Mon Nov 20 14:39:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 67E3737B479; Mon, 20 Nov 2000 14:39:28 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA03845; Mon, 20 Nov 2000 17:39:06 -0500 (EST) Date: Mon, 20 Nov 2000 17:39:06 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Scott Hess , Julian Elischer , jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments In-Reply-To: <200011202156.OAA02067@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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