Re: [PATCH] tick: check if broadcast device could really be stopped

[Benjamin GAIGNARD]

On 10/14/19 3:40 PM, Thomas Gleixner wrote:
> On Mon, 14 Oct 2019, Benjamin GAIGNARD wrote:
>> On 10/14/19 2:56 PM, Thomas Gleixner wrote:
>>> On Wed, 9 Oct 2019, Benjamin Gaignard wrote:
>>>> @@ -78,7 +78,7 @@ static bool tick_check_broadcast_device(struct clock_event_device *curdev,
>>>>    {
>>>>    	if ((newdev->features & CLOCK_EVT_FEAT_DUMMY) ||
>>>>    	    (newdev->features & CLOCK_EVT_FEAT_PERCPU) ||
>>>> -	    (newdev->features & CLOCK_EVT_FEAT_C3STOP))
>>>> +	    tick_broadcast_could_stop(newdev))
>>> No. This might be called _before_ a cpuidle driver is available and then
>>> when that driver is loaded and goes deep, everything goes south.
>> What could be the solution to let know to tick broadcast framework that
>> this device
>>
>> will not be stopped (because CPU won't go in idle) ?
>>
>> I have tried to put "always-on" property on DT but it was a NACK too:
>>
>> https://lkml.org/lkml/2019/9/27/164
>>
>> Do I have miss a flag somewhere ?
> I don't understand what you are trying to achieve here. If the tick device,
> i.e. the comparator stops working in deep idle states, then the device has
> rightfully the CLOCK_EVT_FEAT_C3STOP (mis)feature set. Which means that the
> system needs a fallback device for the deep idle case. If there is no
> physical fallback device then you should enable the hrtimer based broadcast
> pseudo tick device.
>
> If the CPUs never go deep idle because there is no idle driver loaded or
> the deep power state in which the comparator stops working is never
> reached, then the broadcast hrtimer will never be used. It just eats a bit
> of memory and a few extra instructions.

Since CPUs won't go in deep idle I don't want to get a broadcast timer

but only an hrtimer to get accure latencies for the scheduler.

When arch arm timer doesn't set CLOCK_EVT_FEAT_C3STOP flag, my system

got a hrtimer and everything goes well. If arch arm timer set 
CLOCK_EVT_FEAT_C3STOP

hrtimer disappear (except if I add an additional broadcast timer).

What is the link between tick broadcast timer and hrtimer ? Does arch 
arm timer could only

implement them at the same time ?

Benjamin

>
> Thanks,
>
> 	tglx
>