Date: Tue, 14 Dec 1999 06:59:29 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Terry Lambert <tlambert@primenet.com> Cc: adsharma@sharmas.dhs.org, arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <38563121.C6F15E5D@vigrid.com> References: <199912140237.TAA01908@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38563121.C6F15E5D>