x86: Restore the critical section around whole ipi_bitmap_handler() if hardclock IPI is delivered.
ClosedPublic
Actions

Authored by kib on Dec 6 2019, 11:45 PM.

Details

Reviewers

Commits

rS355475: x86: Restore the critical section around whole ipi_bitmap_handler() if

Summary

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

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 28022

Event Timeline

kib created this revision.Dec 6 2019, 11:45 PM

Herald added a subscriber: imp. · View Herald TranscriptDec 6 2019, 11:45 PM

Harbormaster completed remote builds in B28022: Diff 65342.Dec 6 2019, 11:45 PM

kib updated this revision to Diff 65343.Dec 6 2019, 11:49 PM

kib edited the summary of this revision. (Show Details)

Harbormaster completed remote builds in B28023: Diff 65343.Dec 6 2019, 11:49 PM

kib edited the summary of this revision. (Show Details)Dec 6 2019, 11:50 PM

thank you.

sys/x86/x86/mp_x86.c
1267 ↗	(On Diff #65343)	Comment something like: sched_preempt() must be called to clear the pending IPI. However, the critical section will cause extra scheduler lock thrashing when used unconditionally. Only critical_enter() if hardclock must also run.