SurfaceFlinger: use TFD_TIMER_ABSTIME for VSP timer
Using the semantics of alarmIn in VSP timer may lead to lag
if the thread is getting preempted. For example:
Time 0: t1 calls to alarmIn(5)
-- t1 gets preempted for 2ms --
Time 2: t1 calls to timerfd_settime(5)
Time 7: timer wakes up t1, results in 2ms lag
Switching to alarmAt semantics and using TFD_TIMER_ABSTIME to
schedule the timer solves this problem:
Time 0: t1 calls to alarmAt(5)
-- t1 gets preempted for 2ms --
Time 2: t1 calls to timerfd_settime(5)
Time 5: timer wakes up t1
Bug: 159884130
Test: bouncy ball with simulated scheduling delays
Change-Id: I3d727530c2dd47c1a8d1d6a66114d654d7261d87
diff --git a/services/surfaceflinger/Scheduler/Timer.h b/services/surfaceflinger/Scheduler/Timer.h
index a8e2d5a..69ce079 100644
--- a/services/surfaceflinger/Scheduler/Timer.h
+++ b/services/surfaceflinger/Scheduler/Timer.h
@@ -30,9 +30,9 @@
~Timer();
nsecs_t now() const final;
- // NB: alarmIn and alarmCancel are threadsafe; with the last-returning function being effectual
+ // NB: alarmAt and alarmCancel are threadsafe; with the last-returning function being effectual
// Most users will want to serialize thes calls so as to be aware of the timer state.
- void alarmIn(std::function<void()> const& cb, nsecs_t fireIn) final;
+ void alarmAt(std::function<void()> const& cb, nsecs_t time) final;
void alarmCancel() final;
void dump(std::string& result) const final;