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


 176  *
 177  *      If this implied duty cycle is above a maximum pset duty cycle (90%
 178  *      by default), sysdc_update() sets the priority of all SDC threads
 179  *      in that processor set to sysdc_minpri for a "break" period.  After
 180  *      the break period, it waits for a "nobreak" period before trying to
 181  *      enforce the pset duty cycle limit again.
 182  *
 183  * - Processor sets
 184  *
 185  *      As the above implies, SDC is processor set aware, but it does not
 186  *      currently allow threads to change processor sets while in the SDC
 187  *      class.  Instead, those threads must join the desired processor set
 188  *      before entering SDC. [1]
 189  *
 190  * - Batch threads
 191  *
 192  *      A thread joining the SDC class can specify the SDC_THREAD_BATCH
 193  *      flag.  This flag currently has no effect, but marks threads which
 194  *      do bulk processing.
 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  * - Why not FSS?
 223  *
 224  *      It might seem that the existing FSS scheduling class could solve
 225  *      the problems that SDC is attempting to solve.  FSS's more precise
 226  *      solution to the oversubscription problem would hardly cause
 227  *      trouble, as long as it performed well.  SDC is implemented as
 228  *      a separate scheduling class for two main reasons: the initial
 229  *      consumer of SDC does not map well onto the "project" abstraction
 230  *      that is central to FSS, and FSS does not expect to run at kernel
 231  *      priorities.
 232  *
 233  *
 234  * Tunables
 235  *
 236  * - sysdc_update_interval_msec:  Number of milliseconds between
 237  *      consecutive thread priority updates.
 238  *
 239  * - sysdc_reset_interval_msec:  Number of milliseconds between
 240  *      consecutive resets of a thread's base ONPROC and Runnable
 241  *      times.




 176  *
 177  *      If this implied duty cycle is above a maximum pset duty cycle (90%
 178  *      by default), sysdc_update() sets the priority of all SDC threads
 179  *      in that processor set to sysdc_minpri for a "break" period.  After
 180  *      the break period, it waits for a "nobreak" period before trying to
 181  *      enforce the pset duty cycle limit again.
 182  *
 183  * - Processor sets
 184  *
 185  *      As the above implies, SDC is processor set aware, but it does not
 186  *      currently allow threads to change processor sets while in the SDC
 187  *      class.  Instead, those threads must join the desired processor set
 188  *      before entering SDC. [1]
 189  *
 190  * - Batch threads
 191  *
 192  *      A thread joining the SDC class can specify the SDC_THREAD_BATCH
 193  *      flag.  This flag currently has no effect, but marks threads which
 194  *      do bulk processing.
 195  *


























 196  * - Why not FSS?
 197  *
 198  *      It might seem that the existing FSS scheduling class could solve
 199  *      the problems that SDC is attempting to solve.  FSS's more precise
 200  *      solution to the oversubscription problem would hardly cause
 201  *      trouble, as long as it performed well.  SDC is implemented as
 202  *      a separate scheduling class for two main reasons: the initial
 203  *      consumer of SDC does not map well onto the "project" abstraction
 204  *      that is central to FSS, and FSS does not expect to run at kernel
 205  *      priorities.
 206  *
 207  *
 208  * Tunables
 209  *
 210  * - sysdc_update_interval_msec:  Number of milliseconds between
 211  *      consecutive thread priority updates.
 212  *
 213  * - sysdc_reset_interval_msec:  Number of milliseconds between
 214  *      consecutive resets of a thread's base ONPROC and Runnable
 215  *      times.