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.
|