From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: [PATCHv5 01/11] clockevents: Prefer CPU local devices over global devices Date: Fri, 19 Apr 2013 09:19:35 -0700 Message-ID: <1366388385-30722-2-git-send-email-sboyd@codeaurora.org> References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Thomas Gleixner Cc: linux-arm-msm@vger.kernel.org, John Stultz , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-arm-msm@vger.kernel.org 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-by: Mark Rutland Tested-by: Mark Rutland Cc: John Stultz Signed-off-by: Stephen Boyd --- kernel/time/tick-common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 412bcef..d616eca 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -254,9 +254,10 @@ static int tick_check_new_device(struct clock_event_device *newdev) !(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) goto out_bc; /* - * Check the rating + * Check the rating, but prefer CPU local devices */ - if (curdev->rating >= newdev->rating) + if (curdev->rating >= newdev->rating && + cpumask_equal(curdev->cpumask, newdev->cpumask)) goto out_bc; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation From mboxrd@z Thu Jan 1 00:00:00 1970 From: sboyd@codeaurora.org (Stephen Boyd) Date: Fri, 19 Apr 2013 09:19:35 -0700 Subject: [PATCHv5 01/11] clockevents: Prefer CPU local devices over global devices In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org> References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org> Message-ID: <1366388385-30722-2-git-send-email-sboyd@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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-by: Mark Rutland Tested-by: Mark Rutland Cc: John Stultz Signed-off-by: Stephen Boyd --- kernel/time/tick-common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 412bcef..d616eca 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -254,9 +254,10 @@ static int tick_check_new_device(struct clock_event_device *newdev) !(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) goto out_bc; /* - * Check the rating + * Check the rating, but prefer CPU local devices */ - if (curdev->rating >= newdev->rating) + if (curdev->rating >= newdev->rating && + cpumask_equal(curdev->cpumask, newdev->cpumask)) goto out_bc; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030858Ab3DSQXW (ORCPT ); Fri, 19 Apr 2013 12:23:22 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:29403 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756945Ab3DSQTt (ORCPT ); Fri, 19 Apr 2013 12:19:49 -0400 X-IronPort-AV: E=Sophos;i="4.87,510,1363158000"; d="scan'208";a="39797388" From: Stephen Boyd To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, John Stultz Subject: [PATCHv5 01/11] clockevents: Prefer CPU local devices over global devices Date: Fri, 19 Apr 2013 09:19:35 -0700 Message-Id: <1366388385-30722-2-git-send-email-sboyd@codeaurora.org> X-Mailer: git-send-email 1.8.2.1.392.g85e7e81 In-Reply-To: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org> References: <1366388385-30722-1-git-send-email-sboyd@codeaurora.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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-by: Mark Rutland Tested-by: Mark Rutland Cc: John Stultz Signed-off-by: Stephen Boyd --- kernel/time/tick-common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 412bcef..d616eca 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -254,9 +254,10 @@ static int tick_check_new_device(struct clock_event_device *newdev) !(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) goto out_bc; /* - * Check the rating + * Check the rating, but prefer CPU local devices */ - if (curdev->rating >= newdev->rating) + if (curdev->rating >= newdev->rating && + cpumask_equal(curdev->cpumask, newdev->cpumask)) goto out_bc; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation