We introduced (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) as part of
ESTCPULIM() in commit eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any
value in the timeshare range") in order to use more than a fixed number
(40) of all the available priority levels in the timeshare range (136
before the 256-queue runqueue work, 224 now) to take into account the
number of ticks a thread has run ('ts_estcpu').
In the computation of a new thread's priority (resetpriority()), in
addition to the "ticks running" contribution, the final priority also
includes a "nice" value contribution. The final value is clamped into
the [PRI_MIN_TIMESHARE; PRI_MAX_TRIMESHARE] range.
Problem is that the new "ticks running" contribution now can lead to
a computed priority value that exceeds PRI_MAX_TRIMESHARE, and is thus
finally clamped to PRI_MAX_TIMESHARE, which becomes an alias for all
out-of-bound values. In particular, this can conflate CPU-hungry
threads. With at least two of them competing on the same CPU, with an
increase of 'ts_estcpu' of ~64 per second (stathz being 127) and the
minimal decay of 4/5 (load average 2 or more), both threads will easily
reach the current clamping of 224 (+ PRI_MIN_TIMESHARE), and be
considered indifferently by the scheduler.
Fix this problem by ensuring that the maximum contribution of
'ts_estcpu' (via ESTCPULIM()) cannot exceed the timeshare range of
priorities when the nice contribution is added to it, so the nice
contribution continues to have an effect on CPU-bound threads.
Introduction of the nice term in ESTCPULIM() (then NICE_WEIGHT *
PRIO_MAX) has been done in commit bdf423572ee3 ("Scheduler fixes
equivalent to the ones logged in the following NetBSD commit...") and
does not appear to have made any real sense even then.
Fixes: bdf423572ee3 ("Scheduler fixes equivalent to the ones logged in the following NetBSD commit...")
Fixes: eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any value in the timeshare range")
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation