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

[James Hogan <james.hogan@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

Hi,

On Fri, Apr 22, 2016 at 11:40:11AM +0100, James Hogan 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.
> 
> 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.
> 
> 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.
> 
> Instead, borrow the retry pattern from the MIN_ADJUST case, but without
> making adjustments. We retry up to 10 times before giving up.
> 
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>

This is still an issue, both under virtualization and on
hardware-multi-threaded MIPS cores with the mips-gic driver where
general latency can by impacted by the behaviour of software running on
other hardware threads (which are seen as other CPUs from Linux' point
of view) in the same core.

Does anybody have any more feedback about this patch?

Thanks
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]