Messages in this thread | | | Date | Mon, 25 Apr 2016 15:48:58 +0200 | From | Martin Schwidefsky <> | Subject | Re: [PATCH] clockevents: Retry programming min delta up to 10 times |
| |
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.
| |