[lkml]   [2013]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHv7 01/11] clockevents: Prefer CPU local devices over global devices
On 06/06/2013 08:04 PM, Stephen Boyd wrote:
> On 06/06, Daniel Lezcano wrote:
>> 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.
>>> 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 ?
> There is one tick device per-cpu and one broadcast device. The
> broadcast device can only be a global clockevent, whereas the
> per-cpu tick device can be a global clockevent or a per-cpu
> clockevent. The code tries hard to keep per-cpu clockevents in
> the tick device slots but it has an ordering/rating requirement
> that doesn't work when there are only dummy per-cpu devices and
> one global device.
> Perhaps an example will help. Let's say you only have one global
> clockevent such as the sp804, and you have SMP enabled. To
> support SMP we have to register dummy clockevents on each CPU so
> that the sp804 can go into broadcast mode. If we don't do this,
> only the CPU that registered the sp804 will get interrupts while
> the other CPUs will be left with no tick device and thus no
> scheduling. To fix this we register dummy clockevents on all the
> CPUs _before_ we register the sp804 to force the sp804 into the
> broadcast slot. Or we give the dummy clockevents a higher rating
> than the sp804 so that when we register them after the sp804 the
> sp804 is bumped out to broadcast duty.
> If the dummy devices are registered before the sp804 we can give
> the dummies a low rating and the sp804 will still go into the
> broadcast slot due to this code:
> /*
> * If we have a cpu local device already, do not replace it
> * by a non cpu local device
> */
> if (curdev && cpumask_equal(curdev->cpumask, cpumask_of(cpu)))
> goto out_bc;
> If we register the sp804 before the dummies we're also fine as
> long as the rating of the dummy is more than the sp804. Playing
> games with the dummy rating is not very nice so this patch fixes
> it by allowing the per-cpu device to replace the global device no
> matter what the rating of the global device is.
> This fixes the sp804 case when the dummy is rated lower than
> sp804 and it removes any ordering requirement from the
> registration of clockevents. It also completes the logic above
> where we prefer cpu local devices over non cpu local devices.

Thanks for the detailed explanation.

Did Thomas reacted to this patch ?

<> │ Open source software for ARM SoCs

Follow Linaro: <> Facebook |
<!/linaroorg> Twitter |
<> Blog

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2013-06-07 00:41    [W:0.073 / U:6.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site