[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-kernel
Subject:    Re: [PATCH] nohz: Go tickless in lowres full dynticks mode
From:       Viresh Kumar <viresh.kumar () linaro ! org>
Date:       2014-06-30 12:30:35
Message-ID: 75EA049B-1C03-47E8-886F-D7BE6101C1B3 () linaro ! org
[Download RAW message or body]


> On 30-Jun-2014, at 5:14 pm, Preeti U Murthy <preeti@linux.vnet.ibm.com> wrote:
> 
> Hi Viresh,
> 
>> On 06/30/2014 04:53 PM, Viresh Kumar wrote:
>>> On 30 June 2014 16:28, Preeti U Murthy <preeti@linux.vnet.ibm.com> wrote:
>>> I am sceptical about what this patch does when expires is not equal to
>>> KTIME_MAX. This, being the primary timer handler function in the nohz
>>> low resolution mode, it should skip programming *only* when the tick is
>>> stopped, indicating that the cpu was in idle (which this patch takes
>> 
>> or in full dynticks mode..
>> 
>>> care of) and there were no pending timers queued between the time this
>>> cpu went idle and now. If there is a pending timer, it should program
>>> the clock device even if the tick was stopped.
>> 
>> No, we don't need tick just for running timers. We might want to go in
>> full dynticks mode here (not infinitely though), and if the timer is required
>> only after say 100 ticks, we will program clkevt device for this late.
>> 
>> Actually frederic suggested to do something similar in High resolution
>> mode as well, so that we can avoid double set-event for clockevent
>> device. As we will surely get to tick_nohz_stop_sched_tick() as well..
> 
> In high resolution mode, we will still need to program clock device for
> any pending hrtimers in hrtimer_interrupt() right? Only the timer wheel
> is verified in tick_nohz_stop_sched_tick(), isn't it?

Yes. So?
_______________________________________________
linaro-kernel mailing list
linaro-kernel@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-kernel
[prev in list] [next in list] [prev in thread] [next in thread]