Page MenuHomeFreeBSD

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

Authored by kib on Dec 6 2019, 11:45 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 9, 3:48 PM
Unknown Object (File)
Tue, Nov 5, 8:15 AM
Unknown Object (File)
Sep 26 2024, 9:49 PM
Unknown Object (File)
Sep 23 2024, 11:23 PM
Unknown Object (File)
Sep 19 2024, 3:47 PM
Unknown Object (File)
Sep 19 2024, 5:08 AM
Unknown Object (File)
Sep 4 2024, 5:23 AM
Unknown Object (File)
Aug 31 2024, 9:07 PM
Subscribers

Details

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 Not Applicable
Unit
Tests Not Applicable

Event Timeline

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

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.

This revision is now accepted and ready to land.Dec 6 2019, 11:57 PM