From owner-freebsd-arch Tue Dec 14 4: 3:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 403EE14EC0 for ; Tue, 14 Dec 1999 04:03:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA28626 for ; Tue, 14 Dec 1999 13:03:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA62236 for freebsd-arch@freebsd.org; Tue, 14 Dec 1999 13:03:17 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5A1F214CDE for ; Tue, 14 Dec 1999 04:02:05 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt14.pcnet.net [206.105.29.88]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA28671; Tue, 14 Dec 1999 07:01:06 -0500 (EST) Message-ID: <38563121.C6F15E5D@vigrid.com> Date: Tue, 14 Dec 1999 06:59:29 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: adsharma@sharmas.dhs.org, arch@freebsd.org Subject: Re: Recent face to face threads talks. References: <199912140237.TAA01908@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > Editorial note: A "Q" is what I would have called the KSE. A > kernel schedulable entity implies an interaction > with the scheduler, but we are probably going to > get stuck with the current definitions. If so, > I suggest the term SR for "Scheduler Reservation" > is a better fit. I agree also. I thought what we call a KSE should be called a kernel context. > There are only three cases where a "Q" is created: > > o On fork(2) (obviously). > > o When asking to be scheduled on additional CPUs in an > SMP system. It is likely that this particular case > will not require priviledges, or that soft limits > requring priviledges to violate will be implemented > (e.g. an administrative limit of reservations on 4 > CPUs in a 16 CPU system, controlled by the users > login class). > > o When asking for an additional "Q" in order to effect > sheduling priorities of PTHREAD_SCOPE_SYSTEM. It is > likely that dropping priority will be unpriviledged, > and merely result in a UTS designation change, since > creating an additional "Q" would permit the process > to compete as multiple processes against other processes > for quantum (in other words, it would pretend to run the > affected threads at a lower system priority, but in > reality, would not). I agree with everything except I don't think that: > Raising priority is already a > priviledged instruction; it is assumed that raising > priority, by virtue of the fact that it requires > priviledge, will in fact create another "Q". we want to create another Q when the process (Q) priority is changed (raised). An application will create a PTHREAD_SCOPE_SYSTEM thread in an attempt to get another Q, but later (in the created thread) raise the process priority (which will then raise the Q priority). Another Q shouldn't be created when the priority is raised. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message