From patchwork Fri Dec 6 21:52:19 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 3299971 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id E93CCC0D4A for ; Fri, 6 Dec 2013 21:54:33 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 10DA6203B4 for ; Fri, 6 Dec 2013 21:54:33 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C5D22042B for ; Fri, 6 Dec 2013 21:54:31 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Vp3Lq-0007Al-Lf; Fri, 06 Dec 2013 21:54:22 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Vp3Lo-0002ql-1C; Fri, 06 Dec 2013 21:54:20 +0000 Received: from mail.linuxfoundation.org ([140.211.169.12]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Vp3Lk-0002pp-ML for linux-arm-kernel@lists.infradead.org; Fri, 06 Dec 2013 21:54:17 +0000 Received: from localhost (c-76-28-172-123.hsd1.wa.comcast.net [76.28.172.123]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 86F5A8D0; Fri, 6 Dec 2013 21:53:55 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Subject: [PATCH 3.10 48/58] clockevents: Prefer CPU local devices over global devices Date: Fri, 6 Dec 2013 13:52:19 -0800 Message-Id: <20131206214849.344460410@linuxfoundation.org> X-Mailer: git-send-email 1.8.5.1.67.gb00d244 In-Reply-To: <20131206214844.906193530@linuxfoundation.org> References: <20131206214844.906193530@linuxfoundation.org> User-Agent: quilt/0.60-8.1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131206_165416_784440_4CB7A4A3 X-CRM114-Status: GOOD ( 15.50 ) X-Spam-Score: -2.1 (--) Cc: Kim Phillips , Greg Kroah-Hartman , Daniel Lezcano , Stephen Boyd , stable@vger.kernel.org, John Stultz , Thomas Gleixner , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 3.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Stephen Boyd commit 70e5975d3a04be5479a28eec4a2fb10f98ad2785 upstream. On an SMP system with only one global clockevent and a dummy clockevent per CPU we run into problems. We want the dummy clockevents to be registered as the per CPU tick devices, but we can only achieve that if we register the dummy clockevents before the global clockevent or if we artificially inflate the rating of the dummy clockevents to be higher than the rating of the global clockevent. Failure to do so leads to boot hangs when the dummy timers are registered on all other CPUs besides the CPU that accepted the global clockevent as its tick device and there is no broadcast timer to poke the dummy devices. If we're registering multiple clockevents and one clockevent is global and the other is local to a particular CPU we should choose to use the local clockevent regardless of the rating of the device. This way, if the clockevent is a dummy it will take the tick device duty as long as there isn't a higher rated tick device and any global clockevent will be bumped out into broadcast mode, fixing the problem described above. Reported-and-tested-by: Mark Rutland Signed-off-by: Stephen Boyd Tested-by: soren.brinkmann@xilinx.com Cc: John Stultz Cc: Daniel Lezcano Cc: linux-arm-kernel@lists.infradead.org Cc: John Stultz Link: http://lkml.kernel.org/r/20130613183950.GA32061@codeaurora.org Signed-off-by: Thomas Gleixner Cc: Kim Phillips Signed-off-by: Greg Kroah-Hartman --- kernel/time/tick-common.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -234,8 +234,13 @@ static bool tick_check_preferred(struct return false; } - /* Use the higher rated one */ - return !curdev || newdev->rating > curdev->rating; + /* + * Use the higher rated one, but prefer a CPU local device with a lower + * rating than a non-CPU local device + */ + return !curdev || + newdev->rating > curdev->rating || + !cpumask_equal(curdev->cpumask, newdev->cpumask); } /*