Re: [PATCH] clockevents: Retry programming min delta up to 10 times

[Martin Schwidefsky <schwidefsky@de.ibm.com>]

On Fri, 22 Apr 2016 11:40:11 +0100
James Hogan <james.hogan@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.