Time-Sharing parameter table ts_dptbl

The scheduler uses ts_dptbl(4), the time-sharing scheduler (or dispatcher) parameter table, to manage time-sharing LWPs. A default version of ts_dptbl is delivered with the system, and you can change it to suit local needs. First, save a backup of the default version of ts_dptbl. ts_dptbl is specified in the space.c file in the /etc/conf/pack.d/ts directory. It is automatically built into the kernel as part of system configuration.

You can change the size and values of ts_dptbl depending on your local needs. The default values have a long history of good performance over a wide range of environments. Changing the values is not likely to help much, and inappropriate values can have a dramatically negative effect on system performance.

If you do decide to change ts_dptbl, we recommend that you include at least 40 time-sharing global priorities. A range this large gives the scheduler enough leeway to distinguish LWPs based on their CPU use, which it must do to give good response to interactive processes. The default configuration has 60 time-sharing priorities. This example is part of an ts_dptbl:

glbpri	qntm	tqexp	slprt	mxwt	lwt
0,	100,	0,	1,	5,	1,
1,	90,	0,	2,	5,	2,
2,	80,	1,	3,	5,	3,
3,	70,	1,	4,	5,	4,
4,	60,	2,	5,	5,	5,
5,	50,	2,	6,	5,	6,
6,	40,	3,	7,	5,	7,
7,	30,	3,	8,	5,	8,
8,	20,	4,	9,	5,	9,
9,	10,	4,	9,	5,	9,

• The ``glbpri'' column contains global priorities (the priorities that determine when an LWP runs). Higher numbers run first.

  In the table above, the global priorities run from a high of 9 to a low of 0.

• The ``qntm'' column contains the time slice (or quantum) associated with the priority in the ``glbpri'' column; this is the maximum amount of time an LWP with this priority can use the CPU before the scheduler gives another LWP a chance. This time slice is specified in clock ticks. (The system clock ticks HZ times per second, where HZ is a hardware-dependent constant defined in the /usr/include/sys/param_p.h header file.)

  In the table, time slices run from 10 clock ticks for the highest priority LWPs to 100 clock ticks for the lowest priority LWPs.

• The ``tqexp'' column determines the new LWP priority for an LWP whose time slice expires before it sleeps. If an LWP at the priority in the ``glbpri'' column uses its whole time slice without sleeping, the scheduler changes its priority using the ``tqexp'' column as an index back into ts_dptbl: the new priority is the global priority in the ``tqexp'' position in ts_dptbl. (In the configuration shown, the index of an entry in ts_dptbl happens to match the global priority of that entry. However, this match is not necessary.)

  It is usually reasonable to lower the priority of a time-sharing LWP whose time slice expires, because the LWP is too CPU-bound for its current priority. A long, CPU-intensive LWP is an extreme example of such an LWP, and its priority should usually be lowered in favor of LWPs that sleep after a little CPU use and are more likely to be interactive LWPs.

  In the table above, priorities are cut roughly in half when a time slice expires. The lowest priority (0) stays at 0, priority 1 is reduced to 0, priorities 2 and 3 are reduced to 1, and so on.

  Generally, it is a good idea to penalize processes that expire their time slices substantially more than they are rewarded for voluntarily relinquishing the CPU. This helps prevent the CPU from being monopolized at high priority by processes that exhibit a burst of interactive behavior, such as reading a large number of disk blocks, and then change their behavior and become CPU bound.

• The ``slprt'' column gives the priority assigned to an LWP when it returns from a sleep. An LWP may sleep voluntarily, as it does when it makes certain system calls, or involuntarily, as it does when the kernel puts it to sleep after a page fault, for example. It is usually reasonable to raise the priority of an LWP that has slept. It has shown desirable behavior (it gave up the CPU), so we reward it by giving it a higher priority when it awakes.

  In the table above, LWP priorities are incremented by 1 after they sleep, except that the highest time-sharing priority (9) stays the same.

• The ``mxwt'' column specifies the number of seconds an LWP can remain runnable before having its priority changed. (The priority is changed using the ``lwt'' column. See the following explanation for ``lwt''.)

  In the table above, all priorities are recalculated after a wait of 5 seconds.

• The ``lwt'' column gives the new priority for an LWP that is runnable for mxwt seconds without getting its full time slice. It is usually reasonable to raise the priority of an LWP that is not getting any CPU time.

  In the table above, LWP priorities are incremented by 1 when they have been runnable for 5 seconds, except that the highest priority time-sharing priority (9) stays the same.