Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932256AbbGCORi (ORCPT <rfc822;w@1wt.eu>);
	Fri, 3 Jul 2015 10:17:38 -0400
Received: from www.linutronix.de ([62.245.132.108]:48249 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932169AbbGCOR3 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 3 Jul 2015 10:17:29 -0400
Date: Fri, 3 Jul 2015 16:17:13 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Wolfram Sang <wsa@the-dreams.de>
cc: Simon Horman <horms@verge.net.au>, Kevin Hilman <khilman@kernel.org>,
        Tyler Baker <tyler.baker@linaro.org>, Borislav Petkov <bp@alien8.de>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Magnus Damm <magnus.damm@gmail.com>, linux-sh@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: Possible regression due to "tick: broadcast: Prevent livelock
 from event handler"
In-Reply-To: <20150703133245.GA19284@katana>
Message-ID: <alpine.DEB.2.11.1507031612410.3916@nanos>
References: <20150703024044.GB24695@verge.net.au> <20150703105441.GF1521@katana> <alpine.DEB.2.11.1507031511180.3916@nanos> <20150703133245.GA19284@katana>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1154
Lines: 38

On Fri, 3 Jul 2015, Wolfram Sang wrote:

> 
> > So with high res timers it boots. Can you please provide the output of
> > /proc/timer_list for that case?

> Tick Device: mode:     1
> Per CPU device: 0
> Clock Event Device: e0180000.timer
>  max_delta_ns:   131071523464982
>  min_delta_ns:   61035
>  mult:           70369
>  shift:          31
>  mode:           3
>  next_event:     40760000000 nsecs
>  set_next_event: em_sti_clock_event_next
>  set_mode:       em_sti_clock_event_mode
>  event_handler:  hrtimer_interrupt
>  retries:        0

So this is a single core machine and uses the em_sti timer w/o the
broadcast nonsense. In Simons case it looks like em_sti is used as
broadcast device.

Though the issues you see in the highres=n case might be the same as
the ones Simon is observing.

So in that nohz=y highres=n case, does adding idle=poll on the command
line fix the issue?

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/