On Fri, 22 Apr 2016 11:40:11 +0100 James Hogan <james.ho...@imgtec.com> wrote:
> Under virtualisation it is possible to get unexpected latency during a > clockevent device's set_next_event() callback which can make it return > -ETIME even for a delta based on min_delta_ns. Do you have an example for this behavior? I would call that a BUG in the implementation of the clockevent device, no? > The clockevents_program_min_delta() implementation for > CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=n doesn't handle retries when this > happens, nor does clockevents_program_event() or its callers when force > is true (for example hrtimer_reprogram()). This can result in hangs > until the clock event device does a full period. Is that because some clockevent devices can not program the minimum delta in some corner cases? > It isn't appropriate to use MIN_ADJUST in this case as occasional > hypervisor induced high latency will cause min_delta_ns to quickly > increase to the maximum. I agree, the whole minimum delta adjustment is quite broken on a virtualized system. On s390 we have seen the rise of the min_delta_ns to the maximum value due to a busy hypervisor. > Instead, borrow the retry pattern from the MIN_ADJUST case, but without > making adjustments. We retry up to 10 times before giving up. That will add a few unnecessary instruction for architectures that have a sane set_next_event function, namely those that always returns 0. Should not be too bad though. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.