sched_ule: Fix selecting lowest priority thread early in corner case
When transferring a thread with near 100% CPU statistics (but not 100%;
up to 57.5/59≈97.46%) to a CPU where the enqueue offset is ahead of at
least 2 from the dequeue one, which requires peculiar conditions to
happen (transfer triggered by a bind request or cpuset change, or during
balancing if a thread or more existed from a brief amount of time on the
origin CPU), the transferred thread can get placed after the dequeue
offset, effectively making it appear as a high priority one unduly,
causing latency increase for other threads.
The change here was missed when changing the enqueue and dequeue offsets
update mechanism to recover pre-256-queue-runqueue ULE anti-starvation
and fairness behavior. That change opened up the possibility that these
two offsets are apart by more than one.
Reviewed by: markj
Discussed with: Minsoo Choo <minsoo at minsoo.io>
Fixes: 6792f3411f6d ("sched_ule: Recover previous nice and anti-starvation behaviors")
[3 lines not shown]
procdesc: report NOTE_PDSIGCHLD for traced and stopped process
on attach of the knote. It is same as for NOTE_EXIT when attaching to
the exiting process.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58327