Messages in this thread | | | Date | Thu, 25 Jul 2013 15:30:46 +0200 | From | Frederic Weisbecker <> | Subject | Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints |
| |
On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote: > In the current design of timer offload framework, the broadcast cpu should > *not* go into tickless idle so as to avoid missed wakeups on CPUs in deep idle states. > > Since we prevent the CPUs entering deep idle states from programming the lapic of the > broadcast cpu for their respective next local events for reasons mentioned in > PATCH[3/5], the broadcast CPU checks if there are any CPUs to be woken up during > each of its timer interrupt programmed to its local events. > > With tickless idle, the broadcast CPU might not get a timer interrupt till after > many ticks which can result in missed wakeups on CPUs in deep idle states. By > disabling tickless idle, worst case, the tick_sched hrtimer will trigger a > timer interrupt every period to check for broadcast. > > However the current setup of tickless idle does not let us make the choice > of tickless on individual cpus. NOHZ_MODE_INACTIVE which disables tickless idle, > is a system wide setting. Hence resort to an arch specific call to check if a cpu > can go into tickless idle.
Hi Preeti,
I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle mode. I read in the previous patch that's because in dynticks idle mode the broadcast CPU deactivates its lapic so it doesn't receive the IPI. But may be I misunderstood. Anyway that's not good for powersaving.
Also when an arch wants to prevent a CPU from entering dynticks idle mode, it typically use arch_needs_cpu(). May be that could fit for you as well?
Thanks.
| |