From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932684AbcDYNtg (ORCPT ); Mon, 25 Apr 2016 09:49:36 -0400 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:42109 "EHLO e06smtp10.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932231AbcDYNte (ORCPT ); Mon, 25 Apr 2016 09:49:34 -0400 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: schwidefsky@de.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 25 Apr 2016 15:48:58 +0200 From: Martin Schwidefsky To: James Hogan Cc: Thomas Gleixner , Subject: Re: [PATCH] clockevents: Retry programming min delta up to 10 times Message-ID: <20160425154858.7695e109@mschwide> In-Reply-To: <1461321611-6159-1-git-send-email-james.hogan@imgtec.com> References: <1461321611-6159-1-git-send-email-james.hogan@imgtec.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16042513-0041-0000-0000-00001B343E31 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Apr 2016 11:40:11 +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. 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.