Scheduler Activations PSARC 1996/021 1. What specifically is the proposal that we are reviewing? Scheduler activations provides support for applications with special scheduling needs not served by the current system. Client applications include multithreaded applications and database servers. It does this by establishing new channels of communication between the kernel and user-level system libraries. Deliverable components include changes to the kernel, libc, libdoor, libthread, and a new library, libsched. Only the libsched changes involve public interface changes. 2. What is the motivation for it? See attached documentation (Section 1). 3. What is its plan? A full prototype of the system is ready. The design has gone through a series of reviews over the past two years. 4. Are there related projects in Sun? This project depends on the recently approved doors interface upgrade (PSARC 1996/090). No current projects depend on this work. 5. What is the technical content of the project? Please provide diagrams that make the project's interfaces clear. See attached documentation. 6. How is the project delivered into the system? Identify packages, directories, libraries, databases, ...? Code changes to the kernel, libc, libdoor, and libthread. Creation of a new library, /usr/lib/libsched.so.1. Creation of a new header file, /usr/include/schedctl.h. 7. What are the project's hardware platform dependencies? Is it expected to work on SPARC and Intel (and PowerPC)? What will be affected in porting? It will work on all platforms when integrated. 8. System administration: Not applicable. 9. What is its UNIX operational environment: Not applicable. 10. What is its window/desktop operational environment? Not applicable. 11. What are your project's other external interfaces (exported and imported)? See attached documentation (Section 3). The libsched interfaces (including the format of the schedctl_t structure) will be classified Evolving. The intent is to preserve the interfaces for the foreseeable future but allow for the possibility of phasing them out in the future if they become unnecessary (for example, if all database servers are rewritten to be multithreaded and use adaptive mutexes instead of spinlocks). The other interfaces (e.g., the _lwp_schedctl system call) are internal to the project and are classified Consolidation Private. 12. What are its other significant internal interfaces (inter-subsystem and inter-invocation)? See attached documentation (Section 2). 13. How do the interfaces deal with applicable standards? No applicable standards work. The threads library changes support POSIX threads without affecting the interface. 14. Is the interface extensible? How is the interface expected to evolve? - How is versioning handled? - What are the clients over which a change should be managed? How is transistion to a new version to be accomplished? What are the conse- quences to ISV's and their customers? The libsched interface can be extended fairly easily. Nothing in the interface depends on the size of the schedctl_t structure, so it can be expanded as needed without breaking binary compatibility. The only constraint is that the current fields of the structure cannot be moved or changed. In addition, this interface is intended solely for performance. If at some time in the future there is no longer a need for the functionality, it can be removed (leaving the library functions as no-ops) without breaking binary compatibility. This could be a phase in the process of declaring the interface obsolete and EOL'ing it. 15. How do the interfaces adapt to a changing world? - What security issues do you address in your project? One security concern is allowing read/write access to kernel pages by ordinary users through the _lwp_schedctl system call. This is solved by allowing access through the syscall to only those kernel pages allocated exclusively for user-kernel communication. Another is interference between different users. This is solved by partitioning access to the pages according to effective uid. One user can access one set of pages associated with that user's processes; another user has access only to a disjoint set of pages. A third is use by unscrupulous users to take advantage of the system. This is solved by "fail-safe" mechanisms. For example, a user might try to use libsched to block preemption of a process, effectively running that process with the highest possible time-sharing priority. However, after a small number of clock ticks the process must either yield the processor or be preempted and given a lower priority. A separate concern is one of fault isolation. Although there are no security concerns with processes of the same user being able to interfere with one another (since they have permissions to send signals to each other), it would be unfortunate if a "wild pointer" in one process could cause other unrelated processes to crash unexpectedly. Fortunately, the data exported by _lwp_schedctl is not generally vital for the correct execution of an application. If that data is "stepped on" by another process, the main result is possible reduced performance. Thread priority inversion can also occur, but this will be no worse than the current situation where it can occur any time an lwp belonging to a multithreaded process is preempted. 16. What internationalization issues are involved? (if strings are used, how are they accessed? Not applicable. 17. How will the project contribute (positively or negatively) to "system load" and "perceived performance": - What are the performance goals of the project? How were they evaluated? On what type of test platform? There must be no degradation to the performance of applications not using this functionality. This will be evaluated by running standard desktop, time-sharing, networking, and database benchmarks on appropriate systems from each architecture (SPARC, x86, PPC). - MT is standard with Solaris 2.2. What is your project's MT model? This project is (in part) directed at improving support for MT applications. - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? As stated above, the impact on overall system performance should be effectively nil. The main working set of concern is the amount of non-pageable kernel memory used for communication exported via the _lwp_schedctl system call. This is confined only to applications using libthread or libsched, and is kept to a minimum by allowing multiple processes of one user to share the same kernel memory page. The kernel memory usage will grow as the number of users running applications using the libraries increases, but kernel pages are released (when empty) or reused (when not) as lwps and processes exit. 18. How does the project deal with failure and recovery? All state associated with a process is removed when that process exits (by whatever means). 19. Issues? Please identify the issues which you would like the ARC to address. Approval and classification of the libsched interface. 20. Appendices: One-pager and interface documentation.