[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160425154858.7695e109@mschwide>
Date: Mon, 25 Apr 2016 15:48:58 +0200
From: Martin Schwidefsky <schwidefsky@...ibm.com>
To: James Hogan <james.hogan@...tec.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
<linux-kernel@...r.kernel.org>
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@...tec.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.
Powered by blists - more mailing lists