Date: Tue, 31 Jul 2001 16:09:16 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: arch@FreeBSD.ORG Subject: Re: thread scheduling question Message-ID: <Pine.BSF.4.21.0107311606470.35786-100000@InterJet.elischer.org> In-Reply-To: <Pine.SUN.3.91.1010731163310.14566A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
hmmm, ok.. so, as a redux: KSE's in the original KSEG are affected (the original KSEG is affected. New KSEGs created after this, are affected (by default) exisiting other KSEGs are not affected.. Means we need to track which is the original KSEG :-) ALso I LIKE their terminology.. :-) On Tue, 31 Jul 2001, Daniel Eischen wrote: > On Tue, 31 Jul 2001, Julian Elischer wrote: > > Does anyone have any views on what happens when > > the posix scheduling calls are applied against a multithreaded > > process? > > What POSIX scheduling calls? sched_xxx? > > > in particular against one with several KSEGRPs? > > are the multiple KSEs and KSEGRPs visible to the outside at all? > > In general, I think that the sched_xxx (say, sched_setscheduler) > should apply to the process' main (original) KSE Group and not > affect other KSE Groups created for scope system threads. We'll > have another system call (perhaps later on) to allow changing of > those KSE Groups (Solaris has priocntl(2) to allow changing scheduling > parameters by PID, LWPID, PPID, PGID, etc). > > Here's what Solaris 8 has to say about sched_setscheduler (and it's > mostly verbatim from what SUSv2 has to say): > > The effect of this function on individual threads is depen- > dent on the scheduling contention scope of the threads: > > o For threads with system scheduling contention scope, > these functions have no effect on their scheduling. > > o For threads with process scheduling contention scope, > the threads' scheduling parameters will not be > affected. However, the scheduling of these threads > with respect to threads in other processes may be > dependent on the scheduling parameters of their pro- > cess, which are governed using these functions. > > If an implementation supports a two-level scheduling model > in which library threads are multiplexed on top of several > kernel scheduled entities, then the underlying kernel > scheduled entities for the system contention scope threads > will not be affected by these functions. > > The underlying kernel scheduled entities for the process > contention scope threads will have their scheduling parame- > ters changed to the value specified in param. Kernel > scheduled entities for use by process contention scope > threads that are created after this call completes inherit > their scheduling policy and associated scheduling parameters > from the process. > > This function is not atomic with respect to other threads in > the process. Threads are allowed to continue to execute > while this function call is in the process of changing the > scheduling policy for the underlying kernel scheduled enti- > ties used by the process contention scope threads. > > > -- > 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.BSF.4.21.0107311606470.35786-100000>