When processing an IPI, use the correct current time in hardclockintr()
AcceptedPublic
Actions

Authored by jtl on Mar 24 2018, 2:36 PM.

Details

Reviewers

rrs
kib
• hselasky

Summary

When processing an IPI (which is used by remote CPUs to cause the local CPU to reschedule its event timer), the next timer event was scheduled relative to a stale time. This could result in scheduling the event too far in the future.

The fix is to use the correct time.

Test Plan

I ran this against a test which measured the delay encountered by direct timeouts. With this change, the number of unexpected delays appeared to be reduced.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 15772
Build 15784: arc lint + arc unit

Event Timeline

jtl created this revision.Mar 24 2018, 2:36 PM

Herald added a subscriber: imp. · View Herald TranscriptMar 24 2018, 2:36 PM

Harbormaster completed remote builds in B15772: Diff 40689.Mar 24 2018, 2:36 PM

jtl mentioned this in D14828: Avoid a race when we're setting the event timer while going idle.Mar 24 2018, 2:48 PM

kib accepted this revision.Mar 24 2018, 3:03 PM

This revision is now accepted and ready to land.Mar 24 2018, 3:03 PM

• hselasky added inline comments.Mar 26 2018, 3:26 PM

sys/kern/kern_clocksource.c
145	On which platform is this problem occurring? Does it help to declare "now" volatile? Why are you not setting state->now at this point? Did you print the difference between "now" and "sbinuptime()" ?

Revision Contents
Changeset List

Path

Size

sys/

kern/

kern_clocksource.c

2 lines

Diff 40689

View Options

sys/kern/kern_clocksource.c

When processing an IPI, use the correct current time in hardclockintr()AcceptedPublicActions