sun
   microsystems              Systems Architecture Committee

_________________________________________________________________

Subject:       Scheduler Activations

Submitted by:  Andrew T.

File:          psarc/1996/021/opinion.ms

Date:          March 13th, 1996

Committee:     Yousef K., Steve  C.,  Mark  K.,
               Joseph   Kowalski,   Tim  Marsland,  Terrence
               M., Bill S.,  Glenn  Skinner.   Abs-
               tain: Billy F.

1.  Summary

The project introduces scheduler activations  into  Solaris.
Scheduler activations provides support for applications with
special scheduling needs not served by the  current  system.
Client  applications  include multithreaded applications and
database servers.

2.  Decision & Precedence Information

The project is accepted. The project may be delivered  in  a
minor release of Solaris.

3.  Interfaces

The project exports the following interfaces.

_________________________________________________________________________
|                          Interfaces Exported                          |
|_______________|_________________|_____________________________________|
|Interface      |  Classification |  Comments                           |
|_______________|_________________|_____________________________________|
|_lwp_schedctl  |  Project Private|  Used by libthread and libsched only|
|schedctl_init  |  Stable         |  Exported by libsched.so            |
|schedctl_lookup|  Stable         |  Exported by libsched.so            |
|schedctl_exit  |  Stable         |  Exported by libsched.so            |
|schedctl_start |  Stable         |  Exported by libsched.so            |
|schedctl_stop  |  Stable         |  Exported by libsched.so            |
|_______________|_________________|_____________________________________|

4.  Opinion

Communication between libthread (or libsched) and the kernel

psarc/1996/021                    Copyright Sun Microsystems

                           - 2 -

occurs  through  a  shared  memory region. Each process that
uses either  of  these  two  libraries  establishes  such  a
region. The committee discussion centered around the follow-
ing issues related to the shared region.

4.1.  Establishing the shared region

The project team initially proposed establishing the  shared
memory  region by mmaping a device, /dev/sact.  Although the
committee agreed that there is a need for a driver (or  some
other  kernel  component) to handle the shared region imple-
mentation, the committee questioned the  need  to  make  the
device  visible in the file system name space. The committee
recommended that no driver be visible, and instead that  the
shared  memory  region  be  established  using  the lwp_sact
interface.  The  project  team  agreed  to  the  committee's
suggestion,  and  the  documentation to the project has been
updated accordingly.

4.2.  Overhead of shared regions

Since the shared regions are locked in memory, the committee
asked  about  the overhead of this extra locked-down memory.
The project team responded that the amount of  memory  allo-
cated  per-lwp  was  a small number of words.  Moreover, the
memory pages used by the same effective user id  are  shared
among  all processes that belong to that user id. Therefore,
the amount of memory used is small even on systems that make
heavy use of scheduler activations.

4.3.  Changing the user id

The case of a program changing its  effective  user  id  was
discussed.  Since  the  shared memory region is shared among
all processes that have the same user id, it is necessary to
unmap  the  region from a process that changes its effective
user id. The project team indicated that libthread does this
by  interposing  on  setuid(2), unmapping the area, and then
establishing a new mapping using the new effective user id.

4.4.  Clobbering the shared region

The committee wondered what the  effect  of  clobbering  the
shared  region  would be. The team responded that at most, a
process can clobber its own region or that of a process with
the  same  effective  user id.  Clobbering (or not following
the protocol between  the  process  and  the  kernel)  would
result   in   inefficient   scheduling   behavior   for  the
process(es) affected. No process can cause another to  crash
or affect it in any other way.

5.  Minority Opinion

None.

psarc/1996/021                    Copyright Sun Microsystems

                           - 3 -

6.  Advisory Information

None.

7.  Appendices

7.1.  Appendix A: Technical Changes Required

None.

7.2.  Appendix B: Technical Changes Advised

     1.   The project is advised to carefully check for  any
          possible  interaction  between  this  project  and
          future 64-bit interfaces.

     2.   The project is advised to carefully  evaluate  the
          interaction  between  thr_setconcurrency  (3T) and
          schedule activations.

     3.   The project should document the effects of passing
          the wrong pointer to libsched calls.

7.3.  Appendix C: Reference Material

     1.   Andrew    T.,    ``PSARC    20    questions'',
          materials/20questions.txt.

     2.   Andrew    T.,    ``Scheduler    Activations'',
          materials/psarc.ps.

     3.   Andrew   T.,   ``Scheduler   Activations   One
          Pager'', 960117_andrew.t.

psarc/1996/021                    Copyright Sun Microsystems