All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCHv4 01/11] clockevents: Prefer CPU local devices over global devices
Date: Tue, 09 Apr 2013 09:49:27 -0700	[thread overview]
Message-ID: <51644697.2010707@codeaurora.org> (raw)
In-Reply-To: <20130409103303.GV23725@e106331-lin.cambridge.arm.com>

On 04/09/13 03:33, Mark Rutland wrote:
> On Mon, Apr 08, 2013 at 10:27:23PM +0100, 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.
>>
>> 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 might be worth pointing out that if dummy timers are only registered
> when there's more than one CPU, UP behaviour won't degrade from the
> current state of affairs.

Sure, I'll try to come up with something if I have to repost (looks like
I might have to rework the mct change).

>
>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>> Cc: John Stultz <john.stultz@linaro.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>  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 b1600a6..9ea59b9 100644
>> --- a/kernel/time/tick-common.c
>> +++ b/kernel/time/tick-common.c
>> @@ -251,9 +251,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;
>>  	}
> This looks good to me. I tested this on a TC2 with a v3.9-rc6 kernel
> without architected timer support. The patch restores the ability to use
> the sp804 as a broadcast source.
>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
>
> If possible I think this should sit in -next for a bit to make sure it
> doesn't have any unexpected side effects.

Thanks for testing.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 01/11] clockevents: Prefer CPU local devices over global devices
Date: Tue, 09 Apr 2013 09:49:27 -0700	[thread overview]
Message-ID: <51644697.2010707@codeaurora.org> (raw)
In-Reply-To: <20130409103303.GV23725@e106331-lin.cambridge.arm.com>

On 04/09/13 03:33, Mark Rutland wrote:
> On Mon, Apr 08, 2013 at 10:27:23PM +0100, 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.
>>
>> 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 might be worth pointing out that if dummy timers are only registered
> when there's more than one CPU, UP behaviour won't degrade from the
> current state of affairs.

Sure, I'll try to come up with something if I have to repost (looks like
I might have to rework the mct change).

>
>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>> Cc: John Stultz <john.stultz@linaro.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>  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 b1600a6..9ea59b9 100644
>> --- a/kernel/time/tick-common.c
>> +++ b/kernel/time/tick-common.c
>> @@ -251,9 +251,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;
>>  	}
> This looks good to me. I tested this on a TC2 with a v3.9-rc6 kernel
> without architected timer support. The patch restores the ability to use
> the sp804 as a broadcast source.
>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
>
> If possible I think this should sit in -next for a bit to make sure it
> doesn't have any unexpected side effects.

Thanks for testing.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-04-09 16:49 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-08 21:27 [PATCHv4 00/11] Remove ARM local timer API Stephen Boyd
2013-04-08 21:27 ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 01/11] clockevents: Prefer CPU local devices over global devices Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-09 10:33   ` Mark Rutland
2013-04-09 10:33     ` Mark Rutland
2013-04-09 10:33     ` Mark Rutland
2013-04-09 16:49     ` Stephen Boyd [this message]
2013-04-09 16:49       ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 02/11] clocksource: add generic dummy timer driver Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 03/11] ARM: smp: Remove duplicate dummy timer implementation Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 04/11] ARM: smp_twd: Divorce smp_twd from local timer API Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 05/11] ARM: OMAP2+: Divorce " Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 06/11] ARM: EXYNOS4: Divorce mct " Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 07/11] ARM: PRIMA2: Divorce timer-marco " Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 08/11] ARM: msm: Divorce msm_timer " Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 09/11] clocksource: time-armada-370-xp: Fix sparse warning Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 10/11] clocksource: time-armada-370-xp: Divorce from local timer API Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-08 21:27 ` [PATCHv4 11/11] ARM: smp: Remove " Stephen Boyd
2013-04-08 21:27   ` Stephen Boyd
2013-04-17 20:44 ` [PATCHv4 00/11] Remove ARM " Stephen Boyd
2013-04-17 20:44   ` Stephen Boyd
2013-04-18 16:39   ` Olof Johansson
2013-04-18 16:39     ` Olof Johansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51644697.2010707@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.