From sacadmin Wed Jan 16 13:27:07 2008 Received: from sunraf.sfbay.sun.com (sunraf [129.146.177.11]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0GLR6gu002880; Wed, 16 Jan 2008 13:27:06 -0800 (PST) Received: from sunraf.sfbay.sun.com (localhost [127.0.0.1]) by sunraf.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0GLR5WH128634; Wed, 16 Jan 2008 13:27:05 -0800 (PST) Received: (from raf@localhost) by sunraf.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m0GLR5aA128630; Wed, 16 Jan 2008 13:27:05 -0800 (PST) Date: Wed, 16 Jan 2008 13:27:05 -0800 (PST) From: "Roger A. Faulkner" Message-Id: <200801162127.m0GLR5aA128630@sunraf.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: POSIX scheduling interfaces [PSARC/2008/039 FastTrack timeout 01/23/2008] Status: RO Content-Length: 569 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: POSIX scheduling interfaces 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 16 January, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS-NET 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Roger.Faulkner@sun.com Wed Jan 16 13:48:01 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0GLm10P003897 for ; Wed, 16 Jan 2008 13:48:01 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with SMTP id m0GLm0Fn142267; Wed, 16 Jan 2008 13:48:00 -0800 (PST) Message-Id: <200801162148.m0GLm0Fn142267@jurassic-x4600.sfbay.sun.com> Date: Wed, 16 Jan 2008 13:48:00 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: PSARC/2008/039 - POSIX scheduling interfaces To: psarc-ext@sac.sfbay.sun.com Cc: bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Uau0ZpKWqdzPHQ6GH1k5rg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_79 SunOS 5.11 i86pc i386 Status: RO Content-Length: 11322 I am sponsoring this fast-track case for myself. The proposal will time out 01/23/2008 The proposed release binding is "minor release" (do I have that right?) so it can be implemented in Solaris Nevada. I see no need to do a back-port of this amount of change to Solaris 10. This case seeks to make the POSIX standard scheduling interfaces, implemented in libc, compatible with the Solaris scheduler class interfaces, implemented by the priocntl() system call. To this end, it is proposed to expand the list of POSIX-style scheduling policies, defined in , from: #define SCHED_OTHER 0 #define SCHED_FIFO 1 /* run to completion */ #define SCHED_RR 2 /* round-robin */ #define SCHED_SYS 3 /* sys scheduling class */ #define SCHED_IA 4 /* interactive class */ to: #define SCHED_OTHER 0 /* traditional time-sharing scheduling class */ #define SCHED_FIFO 1 /* real-time class: run to completion */ #define SCHED_RR 2 /* real-time class: round-robin */ #define SCHED_SYS 3 /* system scheduling class */ #define SCHED_IA 4 /* interactive time-sharing class */ #define SCHED_FSS 5 /* fair-share scheduling class */ #define SCHED_FX 6 /* fixed-priority scheduling class */ To expunge the old libthread pseudo priority range, defined privately inside of libc (formerly in libthread), altogether: #define THREAD_MIN_PRIORITY 0 /* minimum scheduling pri */ #define THREAD_MAX_PRIORITY 127 /* max scheduling priority */ To make the sched_*() and pthread_*() scheduling interfaces deal with proper priority ranges, as defined by the priocntl(2) interface, not the inverted nice value ranges as is done now for SCHED_OTHER. To change the definition of the subcommand PC_GETPRIRANGE of the priocntl(2) interface and to invent a new PC_DOPRIO subcommand for the priocntl(2) interface, requiring changes to the kernel scheduling class interface: CL_GETCLPRI() Each scheduling class must change its interface definition. CL_DOPRIO() Each scheduling class must inplement this new interface. And finally to change the pthread default 'inheritsched' attribute for pthread_create(3C) from: PTHREAD_EXPLICIT_SCHED to: PTHREAD_INHERIT_SCHED ================================================================ For some background, see these bugids: 1144092 need support for POSIX message passing, scheduling, semaphores, shared memory 4032295 Standards violation - SCHED_RR and SCHED_FIFO defined but not supported This is the bugid relating to this PSARC case: 6647542 POSIX scheduling should be compatible with Solaris scheduling classes ================================================================ History and rationale: Support for POSIX scheduling was added to Solaris in 1994, in the Solaris 2.4 release. Before that time, the only threads scheduling functions available were in libthread: int thr_setprio(thread_t tid, int prio); int thr_getprio(thread_t tid, int *prio); and these defined (internally) the legitimate range of priorities to be: #define THREAD_MIN_PRIORITY 0 /* minimum scheduling pri */ #define THREAD_MAX_PRIORITY 127 /* max scheduling priority */ This was adequate for the time, when the only recognized scheduling class for a multithreaded application was Time-Sharing (TS). However, even at that time there was a mismatch between the notions of priority as expressed by Solaris scheduling classes, manipulated using the priocntl(2) system call and the priocntl(1) command, and priority as expressed by thr_setprio(3C) and thr_getprio(3C). The time-sharing priority range expressed by priocntl(2) was (and is) -60 to +60 as opposed to the range for thr_setprio(3C), 0 to 127. The situation was made a bit more complicated by the system's support for the old notion of a nice(2) value for a time-sharing process, where the range of nice values was (and is) -20 to +20, with lower nice values indicating higher scheduling priority (a nice value of -20 maps roughly into a time-sharing user-level priority of +60). The very old but standardized setpriority(3C) and getpriority(3C) interfaces deal with this range of "priorities" (not real priorities). The situation was made considerably more complicated by the original two-level multithreaded process model, where user-level threads were multiplexed over a usually smaller set of kernel schedulable entities or LWPs (light-weight processes). The thr_setprio(3C) interface applied its notion of priority to user-level threads while the priocntl(2) interface applied its notion of priority to LWPs. Then along came the standardized POSIX scheduling interfaces: sched_setparam(3RT) sched_getparam(3RT) sched_setscheduler(3RT) sched_getscheduler(3RT) sched_get_priority_min(3RT) sched_get_priority_max(3RT) sched_rr_get_interval(3RT) These interfaces introduced the scheduling policies: SCHED_OTHER SCHED_FIFO SCHED_RR along with the possibility of other scheduling policies, defined for the system in the header file. The concept of a priority range per scheduling policy was also introduced. These interfaces all concern themselves with individual processes, not with individual threads. Any process can apply any of these interfaces to itself or to any other process, subject only to permissions. To "apply to a process" means to apply uniformly to every kernel schedulable entity (LWP) within the process. Finally along came the standardized POSIX threads scheduling interfaces: pthread_setschedparam(3C) pthread_getschedparam(3C) pthread_setschedprio(3C) and their adjuncts: pthread_attr_setschedparam(3C) pthread_attr_getschedparam(3C) pthread_attr_setschedpolicy(3C) pthread_attr_getschedpolicy(3C) pthread_mutex_setprioceiling(3C) pthread_mutex_getprioceiling(3C) pthread_mutexattr_setprioceiling(3C) pthread_mutexattr_getprioceiling(3C) The concepts of scheduling policy and per-policy priority range introduced by the sched_*() interfaces are retained by the POSIX threads scheduling interfaces. These interfaces can be applied by one thread of a multithreaded process to itself or to any other thread within the same process, subject only to permissions. There is no way for a thread in one process to apply these interfaces to a thread in a different process. Except for the pseudo priority range of THREAD_MIN_PRIORITY to THREAD_MAX_PRIORITY, all of these scheduling interfaces can be supported at the bottom level by the powerful but complex priocntl(2) interface, augmented by the individual scheduling class specific interfaces defined for the time-sharing (TS), real-time (RT), interactive (IA), fair-share (FSS), and fixed priority (FX) scheduling classes. Actions to be taken: The pseudo priority concepts and the definitions of THREAD_MIN_PRIORITY and THREAD_MAX_PRIORITY should be expunged. They are useless now that the two-level threading model has been abandoned. The supported scheduling classes should be formalized as appropriate scheduling policies, defined in the header file: #define SCHED_OTHER 0 /* traditional time-sharing scheduling class */ #define SCHED_FIFO 1 /* real-time class: run to completion */ #define SCHED_RR 2 /* real-time class: round-robin */ #define SCHED_SYS 3 /* system scheduling class */ #define SCHED_IA 4 /* interactive time-sharing class */ #define SCHED_FSS 5 /* fair-share scheduling class */ #define SCHED_FX 6 /* fixed-priority scheduling class */ #define _SCHED_NEXT 7 /* first unassigned policy number */ Since Solaris supports third-party scheduling classes, provision must be made in the sched_*() and pthread_*() scheduling interfaces to support dynamically-loaded third party scheduling classes by returning a unique policy number, beyond _SCHED_NEXT, for each interface that returns a policy number. The sched_*() and pthread_*() scheduling interfaces should deal with proper priority ranges, as defined by the priocntl(2) interface, not the inverted nice value ranges as is done now for SCHED_OTHER. Since a thread's scheduling class and priority may be changed at any time, without notice and out of control of the thread itself, provision must be made to communicate the current scheduling class and priority to a thread from the kernel. This can be accomplished with an extension to the private schedctl() interface to include the thread's scheduling class id, the thread's priority within that class, and in addition, the current kernel-computed dispatch priority. To enable a thread's class priority to be manipulated independently of its class id, two changes to the priocntl() interface are required: PC_GETPRIRANGE Change the definition of the operation from "return the global scheduling priority range of the class" to "return the user-mode scheduling priority range of the class". PC_DOPRIO New operation: Class-independent method for getting or setting the user-mode priority within the current class. These changes require changes to the kernel scheduling class interface: CL_GETCLPRI() Each scheduling class must change its interface definition. CL_DOPRIO() Each scheduling class must inplement this new interface. These operations enable the POSIX scheduling interfaces to work on a thread running in a third-party scheduling class (whose policy is not defined in the header file) so long as the third-party code implements the CL_GETCLPRI() and CL_DOPRIO() interfaces properly. Finally, the default attributes for creating a thread with pthread_create() include PTHREAD_EXPLICIT_SCHED. This is unnatural. For one thing, it subverts the intent of setting the default scheduling class for processes in a zone, often the fair-share class (FSS). The main thread would be born (at exec() time) using the default scheduling class, but each thread created by pthread_create() using the default attributes would attempt to be placed in the SCHED_OTHER (time-sharing) scheduling class. Likewise, a real-time process (RT class) would have its additional threads created in the time-sharing class by default. The default value for this attribute should be PTHREAD_INHERIT_SCHED so that a thread, by default, inherits its scheduling policy and priority from the creating thread. It obeys the principle of least surprise. All of these changes require changes to the following manual pages: getpriority.3c priocntl.1 priocntl.2 priocntlset.2 pthread_attr_getschedparam.3c pthread_attr_getschedpolicy.3c pthread_attr_init.3c pthread_getschedparam.3c pthread_mutex_getprioceiling.3c pthread_mutexattr_getprioceiling.3c pthread_setschedprio.3c sched.h.3head sched_get_priority_max.3rt sched_getparam.3rt sched_getscheduler.3rt sched_rr_get_interval.3rt sched_setparam.3rt sched_setscheduler.3rt td_thr_setprio.3c_db thr_getprio.3c threads.5 See the materials/old_man and materials/new_man directories for the old and new versions of these manual pages. Use diff(1) to see the changes. Roger Faulkner From glenn.skinner@sun.com Thu Jan 17 10:25:28 2008 Received: from ivrel.sfbay.sun.com (ivrel [129.146.74.76]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0HIPSIa004832 for ; Thu, 17 Jan 2008 10:25:28 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m0HIPRP9018423; Thu, 17 Jan 2008 10:25:27 -0800 (PST) Message-Id: <200801171825.m0HIPRP9018423@ivrel.sfbay.sun.com> Date: Thu, 17 Jan 2008 10:25:27 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2008/039 [POSIX scheduling interfaces] To: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com Cc: bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1k0/TE9DRdNMrA0pgyx0uA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 3030 Date: Wed, 16 Jan 2008 13:48:00 -0800 (PST) From: "Roger A. Faulkner" Subject: PSARC/2008/039 - POSIX scheduling interfaces The proposed release binding is "minor release" (do I have that right?) so it can be implemented in Solaris Nevada. I see no need to do a back-port of this amount of change to Solaris 10. This case seeks to make the POSIX standard scheduling interfaces, implemented in libc, compatible with the Solaris scheduler class interfaces, implemented by the priocntl() system call. To this end, it is proposed to expand the list of POSIX-style scheduling policies, defined in , from: #define SCHED_OTHER 0 #define SCHED_FIFO 1 /* run to completion */ #define SCHED_RR 2 /* round-robin */ #define SCHED_SYS 3 /* sys scheduling class */ #define SCHED_IA 4 /* interactive class */ to: #define SCHED_OTHER 0 /* traditional time-sharing scheduling class */ #define SCHED_FIFO 1 /* real-time class: run to completion */ #define SCHED_RR 2 /* real-time class: round-robin */ #define SCHED_SYS 3 /* system scheduling class */ #define SCHED_IA 4 /* interactive time-sharing class */ #define SCHED_FSS 5 /* fair-share scheduling class */ #define SCHED_FX 6 /* fixed-priority scheduling class */ To expunge the old libthread pseudo priority range, defined privately inside of libc (formerly in libthread), altogether: #define THREAD_MIN_PRIORITY 0 /* minimum scheduling pri */ #define THREAD_MAX_PRIORITY 127 /* max scheduling priority */ So far, so good... To make the sched_*() and pthread_*() scheduling interfaces deal with proper priority ranges, as defined by the priocntl(2) interface, not the inverted nice value ranges as is done now for SCHED_OTHER. ... but this change introduces an incompatibility, does it not? To change the definition of the subcommand PC_GETPRIRANGE of the priocntl(2) interface and to invent a new PC_DOPRIO subcommand for the priocntl(2) interface, requiring changes to the kernel scheduling class interface: CL_GETCLPRI() Each scheduling class must change its interface definition. CL_DOPRIO() Each scheduling class must inplement this new interface. And finally to change the pthread default 'inheritsched' attribute for pthread_create(3C) from: PTHREAD_EXPLICIT_SCHED to: PTHREAD_INHERIT_SCHED And don't these as well (excepting adding PD_DOPRIO)? What stability level do the symbols you plan to remove have? What stability levels do you propose for their replacements? What will/might break should this project integrate as proposed? (What's your best assessment of who or what might depend on the things the project makes incompatible changes to?) -- Glenn From Roger.Faulkner@sun.com Thu Jan 17 12:25:23 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0HKPMvX009056 for ; Thu, 17 Jan 2008 12:25:22 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with SMTP id m0HKPMKM297161; Thu, 17 Jan 2008 12:25:22 -0800 (PST) Message-Id: <200801172025.m0HKPMKM297161@jurassic-x4600.sfbay.sun.com> Date: Thu, 17 Jan 2008 12:25:22 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: 2008/039 [POSIX scheduling interfaces] To: psarc-ext@sac.sfbay.sun.com, glenn.skinner@sun.com Cc: bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XzmlCf+FMsZmEhSXmhBDmw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_79 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2363 > Date: Thu, 17 Jan 2008 10:25:27 -0800 (PST) > From: Glenn Skinner > Subject: Re: 2008/039 [POSIX scheduling interfaces] > To: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com > Cc: bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com > ... > So far, so good... > > To make the sched_*() and pthread_*() scheduling interfaces deal > with proper priority ranges, as defined by the priocntl(2) > interface, not the inverted nice value ranges as is done now for > SCHED_OTHER. > > ... but this change introduces an incompatibility, does it not? Yes, but it rectifies a standards violation. The standards interfaces require priorities, low to high, to reflect real scheduling priorities, low to high. See the bugids: 6379296 UNIX03: *vsrte* pthread_mutex_timedlock 8, 9 fail because thread did not inherit priority 6466689 UNIX03: *vsrt* sched_get_priority_max 1 fails, pthread_setschedparam set prio above max The old behavior of returning nice values (inverted at that) was just a badly mistaken bug. > To change the definition of the subcommand > PC_GETPRIRANGE > of the priocntl(2) interface and to invent a new > PC_DOPRIO > subcommand for the priocntl(2) interface, requiring > changes to the kernel scheduling class interface: > CL_GETCLPRI() > Each scheduling class must change its interface definition. > CL_DOPRIO() > Each scheduling class must inplement this new interface. > > And finally to change the pthread default 'inheritsched' attribute > for pthread_create(3C) from: > PTHREAD_EXPLICIT_SCHED > to: > PTHREAD_INHERIT_SCHED > > And don't these as well (excepting adding PD_DOPRIO)? > > What stability level do the symbols you plan to remove have? What > stability levels do you propose for their replacements? What > will/might break should this project integrate as proposed? (What's > your best assessment of who or what might depend on the things the > project makes incompatible changes to?) Well, my understanding of the scheduler class interfaces in the kernel is that it is all uncommitted, unstable, whatever. Not even as high as 'evolving'. The priocntl() interfaces are a bit higher, but the PC_GETPRIRANGE subcommand in particular is consolidation private: From : Status: RO Content-Length: 939 #define PC_GETPRIRANGE 5 /* Get global priority range for a class */ /* posix.4 scheduling, not for general use */ and my addition to this file should also be consolidation private: #define PC_DOPRIO 11 /* Set or get priority, not for general use */ I'm not deleting any visible symbols. The THREAD_MIN_PRIORITY and THREAD_MAX_PRIORITY were never visible as themselves. Only thr_setprio() and thr_getprio() ever documented their ranges. What will break? It's hard to say. Something that actually believed the old stuff worked, I guess. (It never did.) Certainly, third-party scheduling classes will break. But I couldn't find any using Google. The most important thing to support is actual real-time threads and processes, and the SCHED_RR and SCHED_FIFO interfaces remain the same as before. (The old stuff actually worked for real-time.) Roger From glenn.skinner@sun.com Thu Jan 17 13:00:48 2008 Received: from ivrel.sfbay.sun.com (ivrel [129.146.74.76]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0HL0mYZ010022 for ; Thu, 17 Jan 2008 13:00:48 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m0HL0mk0018716; Thu, 17 Jan 2008 13:00:48 -0800 (PST) Message-Id: <200801172100.m0HL0mk0018716@ivrel.sfbay.sun.com> Date: Thu, 17 Jan 2008 13:00:48 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2008/039 [POSIX scheduling interfaces] To: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com Cc: bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9W2ot0S0bBBROCJqmD2VEw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1833 Date: Thu, 17 Jan 2008 12:25:22 -0800 (PST) From: "Roger A. Faulkner" Subject: Re: 2008/039 [POSIX scheduling interfaces] > Date: Thu, 17 Jan 2008 10:25:27 -0800 (PST) > From: Glenn Skinner > Subject: Re: 2008/039 [POSIX scheduling interfaces] > [various questions concerning stability and compatibility] ... Yes, but it rectifies a standards violation. The standards interfaces require priorities, low to high, to reflect real scheduling priorities, low to high. The old behavior of returning nice values (inverted at that) was just a badly mistaken bug. ... Well, my understanding of the scheduler class interfaces in the kernel is that it is all uncommitted, unstable, whatever. Not even as high as 'evolving'. The priocntl() interfaces are a bit higher, but the PC_GETPRIRANGE subcommand in particular is consolidation private: From : #define PC_GETPRIRANGE 5 /* Get global priority range for a class */ /* posix.4 scheduling, not for general use */ and my addition to this file should also be consolidation private: #define PC_DOPRIO 11 /* Set or get priority, not for general use */ I'm not deleting any visible symbols. The THREAD_MIN_PRIORITY and THREAD_MAX_PRIORITY were never visible as themselves. Only thr_setprio() and thr_getprio() ever documented their ranges. What will break? It's hard to say. Something that actually believed the old stuff worked, I guess. (It never did.) Certainly, third-party scheduling classes will break. But I couldn't find any using Google. Ok, that's what I wanted to know and I'm satisfied with the answers. Thanks! -- Glenn From jek3@sun.com Thu Jan 17 13:58:26 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0HLwQ22012064 for ; Thu, 17 Jan 2008 13:58:26 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0HLwPjc314471; Thu, 17 Jan 2008 13:58:25 -0800 (PST) Message-ID: <478FCF40.4010600@sun.com> Date: Thu, 17 Jan 2008 11:57:20 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0.0.6 (X11/20071119) MIME-Version: 1.0 To: Glenn Skinner CC: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com, bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com Subject: Re: 2008/039 [POSIX scheduling interfaces] References: <200801172100.m0HL0mk0018716@ivrel.sfbay.sun.com> In-Reply-To: <200801172100.m0HL0mk0018716@ivrel.sfbay.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2204 Glenn Skinner wrote: > Date: Thu, 17 Jan 2008 12:25:22 -0800 (PST) > From: "Roger A. Faulkner" > Subject: Re: 2008/039 [POSIX scheduling interfaces] > > > Date: Thu, 17 Jan 2008 10:25:27 -0800 (PST) > > From: Glenn Skinner > > Subject: Re: 2008/039 [POSIX scheduling interfaces] > > > [various questions concerning stability and compatibility] > > ... > Yes, but it rectifies a standards violation. The standards > interfaces require priorities, low to high, to reflect real > scheduling priorities, low to high. > > The old behavior of returning nice values (inverted at that) was > just a badly mistaken bug. > > ... > Well, my understanding of the scheduler class interfaces in the > kernel is that it is all uncommitted, unstable, whatever. Not > even as high as 'evolving'. > > The priocntl() interfaces are a bit higher, but the PC_GETPRIRANGE > subcommand in particular is consolidation private: > > From : > > #define PC_GETPRIRANGE 5 /* Get global priority range for a class */ > /* posix.4 scheduling, not for general use */ > > and my addition to this file should also be consolidation private: > > #define PC_DOPRIO 11 /* Set or get priority, not for general use */ > > I'm not deleting any visible symbols. The THREAD_MIN_PRIORITY and > THREAD_MAX_PRIORITY were never visible as themselves. Only > thr_setprio() and thr_getprio() ever documented their ranges. > > What will break? It's hard to say. Something that actually > believed the old stuff worked, I guess. (It never did.) > > Certainly, third-party scheduling classes will break. > But I couldn't find any using Google. > > Ok, that's what I wanted to know and I'm satisfied with the answers. > Thanks! > > -- Glenn > After raf's posting, I want to check and clarify the commitments, which will take me a day or so. I agree that what raf is doing is the right thing (I remember some of these issues), so at most this will result in a few more words in raf's proposal. - jek3 From Roger.Faulkner@sun.com Sun Jan 27 22:08:39 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S68dgZ002635 for ; Sun, 27 Jan 2008 22:08:39 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with SMTP id m0S68dXp774943; Sun, 27 Jan 2008 22:08:39 -0800 (PST) Message-Id: <200801280608.m0S68dXp774943@jurassic-x4600.sfbay.sun.com> Date: Sun, 27 Jan 2008 22:08:39 -0800 (PST) From: "Roger A. Faulkner" Reply-To: "Roger A. Faulkner" Subject: Re: 2008/039 [POSIX scheduling interfaces] To: glenn.skinner@sun.com, jek3@sun.com Cc: psarc-ext@sac.sfbay.sun.com, bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dFtA7Nmo4uE/owK+EMgLfw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_79 SunOS 5.11 i86pc i386 Status: RO Content-Length: 773 > Date: Thu, 17 Jan 2008 11:57:20 -1000 > From: Joseph Kowalski > Subject: Re: 2008/039 [POSIX scheduling interfaces] > To: Glenn Skinner > Cc: psarc-ext@sac.sfbay.sun.com, Roger.Faulkner@sun.com, bart.smaalders@sun.com, john.zolnowsky@sun.com, darrin.johnson@sun.com > > After raf's posting, I want to check and clarify the commitments, which > will take > me a day or so. I agree that what raf is doing is the right thing (I > remember some > of these issues), so at most this will result in a few more words in > raf's proposal. > > - jek3 Joe: Any update on checking and clarifying? I see that /shared/sac/PSARC/stat.out still has this case marked waiting fast-track 01/23/2008 even though the date has passed. Roger From carlsonj@phorcys.east.sun.com Mon Jan 28 04:18:35 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0SCIYKk009152 for ; Mon, 28 Jan 2008 04:18:35 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0SCIY8L020226; Mon, 28 Jan 2008 07:18:34 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m0SCIY6o020223; Mon, 28 Jan 2008 07:18:34 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18333.51226.526929.788235@gargle.gargle.HOWL> Date: Mon, 28 Jan 2008 07:18:34 -0500 From: James Carlson To: "Roger A. Faulkner" Cc: glenn.skinner@sun.com, jek3@sun.com, psarc-ext@sac.sfbay.sun.com, bart.smaalders@sun.com, John.Zolnowsky@sun.com, Darrin.Johnson@sun.com Subject: Re: 2008/039 [POSIX scheduling interfaces] In-Reply-To: <200801280608.m0S68dXp774943@jurassic-x4600.sfbay.sun.com> References: <200801280608.m0S68dXp774943@jurassic-x4600.sfbay.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 843 Roger A. Faulkner writes: > Any update on checking and clarifying? As usual, and as expected, we talked about this case during our regularly scheduled ARC meeting on the 23rd. Neither Joe nor the submitter showed, and Joe hadn't asked for more time. Looking at the comments, it didn't sound like there were outstanding architectural questions, so we approved it then. > I see that /shared/sac/PSARC/stat.out still has this > case marked waiting fast-track 01/23/2008 even though > the date has passed. It's the case sponsor who is responsible for keeping up with the status and setting the IAM file appropriately. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From jek3@sun.com Mon Jan 28 12:09:47 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0SK9lDD020706 for ; Mon, 28 Jan 2008 12:09:47 -0800 (PST) Received: from [129.150.12.37] (vpn-129-150-12-37.SFBay.Sun.COM [129.150.12.37]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0SK9kWG858350; Mon, 28 Jan 2008 12:09:47 -0800 (PST) Message-ID: <479E3638.304@sun.com> Date: Mon, 28 Jan 2008 10:08:24 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0.0.6 (X11/20071119) MIME-Version: 1.0 To: James Carlson CC: "Roger A. Faulkner" , glenn.skinner@sun.com, psarc-ext@sac.sfbay.sun.com, bart.smaalders@sun.com, John.Zolnowsky@sun.com, Darrin.Johnson@sun.com Subject: Re: 2008/039 [POSIX scheduling interfaces] References: <200801280608.m0S68dXp774943@jurassic-x4600.sfbay.sun.com> <18333.51226.526929.788235@gargle.gargle.HOWL> In-Reply-To: <18333.51226.526929.788235@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 861 James Carlson wrote: > Roger A. Faulkner writes: > >> Any update on checking and clarifying? >> > > As usual, and as expected, we talked about this case during our > regularly scheduled ARC meeting on the 23rd. Neither Joe nor the > submitter showed, and Joe hadn't asked for more time. Looking at the > comments, it didn't sound like there were outstanding architectural > questions, so we approved it then. > > >> I see that /shared/sac/PSARC/stat.out still has this >> case marked waiting fast-track 01/23/2008 even though >> the date has passed. >> > > It's the case sponsor who is responsible for keeping up with the > status and setting the IAM file appropriately. > Yea, I didn't get to this (my ISP was off more than on). Just ignore it. Its probably not that important anyway - just crossing t's that can do with out it. - jek3