From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lezcano Subject: Re: [PATCHv7 01/11] clockevents: Prefer CPU local devices over global devices Date: Thu, 06 Jun 2013 17:12:40 +0200 Message-ID: <51B0A6E8.20909@linaro.org> References: <1370291642-13259-1-git-send-email-sboyd@codeaurora.org> <1370291642-13259-2-git-send-email-sboyd@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-bk0-f53.google.com ([209.85.214.53]:65306 "EHLO mail-bk0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978Ab3FFPMp (ORCPT ); Thu, 6 Jun 2013 11:12:45 -0400 Received: by mail-bk0-f53.google.com with SMTP id e11so1078082bkh.40 for ; Thu, 06 Jun 2013 08:12:44 -0700 (PDT) In-Reply-To: <1370291642-13259-2-git-send-email-sboyd@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Stephen Boyd Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, John Stultz , Thomas Gleixner On 06/03/2013 10:33 PM, Stephen Boyd wrote: > 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. >=20 > 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. It is not clear the connection between the changelog, the patch and the comment. Could you clarify a bit ? Thanks -- Daniel > Reported-by: Mark Rutland > Tested-by: Mark Rutland > Tested-by: S=C3=B6ren Brinkmann > Acked-by: Marc Zyngier , > Cc: John Stultz > Cc: Thomas Gleixner > Cc: Daniel Lezcano > Signed-off-by: Stephen Boyd > --- > kernel/time/tick-common.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) >=20 > diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c > index 5d3fb10..3da62de 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_ev= ent_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 >=3D newdev->rating) > + if (curdev->rating >=3D newdev->rating && > + cpumask_equal(curdev->cpumask, newdev->cpumask)) > goto out_bc; > } > =20 >=20 --=20 Linaro.org =E2=94=82 Open source software for= ARM SoCs =46ollow Linaro: Facebook | Twitter | Blog