Hi Frederic, On 07/25/2013 07:00 PM, Frederic Weisbecker wrote: > 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?
Yes this will suit our requirement perfectly. I will note down this change for the next version of this patchset. Thank you very much for pointing this out :) Regards Preeti U Murthy _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
