|
Description
|
Time-share scheduling class supports nice levels by making threads use
smaller priority ranges instead of the default 0 to 59 priority range.
Threads with positive nice values get their tsproc_t->ts_upri fields
set to negative values (all the way down to -59). Threads with negative
nice values get their ts_upri fields set to positive values (all the
way up to 60).
The following macro is used to calculate new usermode priority for
a given thread based on its CPU priority, nice level (user priority)
and interactivity boost:
#define TS_NEWUMDPRI(tspp) \
{ \
pri_t pri; \
pri = (tspp)->ts_cpupri + (tspp)->ts_upri + (tspp)->ts_boost; \
if (pri > ts_maxumdpri) \
(tspp)->ts_umdpri = ts_maxumdpri; \
else if (pri < 0) \
(tspp)->ts_umdpri = 0; \
else \
(tspp)->ts_umdpri = pri; \
ASSERT((tspp)->ts_umdpri >= 0 && (tspp)->ts_umdpri <= ts_maxumdpri);
\
}
So, what happens is that positively niced threads end up running in the
low priority band. When there are many threads running with negative
nice levels at the same time (which will end up running in high priority
band), positively niced threads get starved. That's the problem.
The idea of how to solve it was to make it so that threads which
can't get scheduled in one second (because of their low priority)
would still get their priority bumped up to 59. Also, threads with
positive nice values would have their priorities drop down faster on
time quantum expirations. And vice versa, threads with negative nice values
would see their priorities drop down slower (as if their usage of CPU
cycles is less costly compared to positively niced threads).
|