Justification for this change is to avoid disturbing ULE's behavior too
much at this time. We however acknowledge that the effect of "nice"
values is extremely weak and will most probably change going forward.
Tuning allows to mostly recover ULE's behavior prior to the switch to
a single 256-queue runqueue and the increase of the timesharing priority
levels' range.
After this change, in a series of test involving two long-running
processes with varying nice values competing for the same CPU, we
observe that used CPU time ratios of the highest priority process to
change by at most 1.15% and on average by 0.46% (absolute differences).
In relative differences, they change by at most 2% and on average by
0.78%.
In order to preserve these ratios, as the number of priority levels
alloted to the timesharing policy have been raised from 136 to 168, we
keep the ratio of levels reserved to handle nice values to that
reserved for CPU usage by applying a factor of 5/4 (which is close to
168/136).
Time-based advance of the timesharing circular queue's head is ULE's
main fairness and anti-starvation mechanism. The higher number of
timesharing queues is now compensated by allowing a greater increment of
the head offset per tick. Because there are now 112 queue levels
dedicated to the timesharing policy, whereas there previously were 64
(priorities spread into a single, separate runqueue), the circular
queue's head must progress 7/4 faster.
While here, take into 'cnt' as the number of ticks when advancing the
circular queue's head. This fix depends on the other code changes
enabling incrementation by more than one.