Print this page
OS-7753 THREAD_KPRI_RELEASE does nothing of the sort
Reviewed by: Bryan Cantrill <bryan@joyent.com>
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>

Split Close
Expand all
Collapse all
          --- old/usr/src/uts/common/disp/sysdc.c
          +++ new/usr/src/uts/common/disp/sysdc.c
↓ open down ↓ 185 lines elided ↑ open up ↑
 186  186   *      currently allow threads to change processor sets while in the SDC
 187  187   *      class.  Instead, those threads must join the desired processor set
 188  188   *      before entering SDC. [1]
 189  189   *
 190  190   * - Batch threads
 191  191   *
 192  192   *      A thread joining the SDC class can specify the SDC_THREAD_BATCH
 193  193   *      flag.  This flag currently has no effect, but marks threads which
 194  194   *      do bulk processing.
 195  195   *
 196      - * - t_kpri_req
 197      - *
 198      - *      The TS and FSS scheduling classes pay attention to t_kpri_req,
 199      - *      which provides a simple form of priority inheritance for
 200      - *      synchronization primitives (such as rwlocks held as READER) which
 201      - *      cannot be traced to a unique thread.  The SDC class does not honor
 202      - *      t_kpri_req, for a few reasons:
 203      - *
 204      - *      1.  t_kpri_req is notoriously inaccurate.  A measure of its
 205      - *          inaccuracy is that it needs to be cleared every time a thread
 206      - *          returns to user mode, because it is frequently non-zero at that
 207      - *          point.  This can happen because "ownership" of synchronization
 208      - *          primitives that use t_kpri_req can be silently handed off,
 209      - *          leaving no opportunity to will the t_kpri_req inheritance.
 210      - *
 211      - *      2.  Unlike in TS and FSS, threads in SDC *will* eventually run at
 212      - *          kernel priority.  This means that even if an SDC thread
 213      - *          is holding a synchronization primitive and running at low
 214      - *          priority, its priority will eventually be raised above 60,
 215      - *          allowing it to drive on and release the resource.
 216      - *
 217      - *      3.  The first consumer of SDC uses the taskq subsystem, which holds
 218      - *          a reader lock for the duration of the task's execution.  This
 219      - *          would mean that SDC threads would never drop below kernel
 220      - *          priority in practice, which defeats one of the purposes of SDC.
 221      - *
 222  196   * - Why not FSS?
 223  197   *
 224  198   *      It might seem that the existing FSS scheduling class could solve
 225  199   *      the problems that SDC is attempting to solve.  FSS's more precise
 226  200   *      solution to the oversubscription problem would hardly cause
 227  201   *      trouble, as long as it performed well.  SDC is implemented as
 228  202   *      a separate scheduling class for two main reasons: the initial
 229  203   *      consumer of SDC does not map well onto the "project" abstraction
 230  204   *      that is central to FSS, and FSS does not expect to run at kernel
 231  205   *      priorities.
↓ open down ↓ 1086 lines elided ↑ open up ↑
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX