Change Details

In the current code after r355311, critical section is taken only around hardclockintr() call, and sched_preempt() is called after the section is exited. If we reschedule after exit, as we typically would due to conditions that caused IPI, in ULE the runq tdq_ipipending is not cleared, which blocks generation of further preempt IPIs. Since all relatively modern (10 years) hardware has per-cpu event timers, restoring the critical section conditionally does not affect it. Diagnosed and reviewed by: jeff Reported and tested by: cy

In the current code after r355311, critical section is taken only around hardclockintr() call, and sched_preempt() is called after the section is exited. If we reschedule after exit, as we typically would due to conditions that caused IPI, in ULE the runq tdq_ipipending is not cleared, which blocks generation of further preempt IPIs. Also restore ordering of hardclock before sched_preempt(), to recalculate thread priority in statclock() before checking it. Since all relatively modern (10 years) hardware has per-cpu event timers, restoring the critical section conditionally does not affect it. Diagnosed and reviewed by: jeff Reported and tested by: cy

In the current code after r355311, critical section is taken only around hardclockintr() call, and sched_preempt() is called after the section is exited. If we reschedule after exit, as we typically would due to conditions that caused IPI, in ULE the runq tdq_ipipending is not cleared, which blocks generation of further preempt IPIs. Also restore ordering of hardclock before sched_preempt(), to recalculate thread priority in statclock() before checking it. Since all relatively modern (10 years) hardware has per-cpu event timers, restoring the critical section conditionally does not affect it. Diagnosed and reviewed by: jeff Reported and tested by: cy