[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1312021859440.30673@ionos.tec.linutronix.de>
Date: Mon, 2 Dec 2013 19:00:20 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Preeti U Murthy <preeti@...ux.vnet.ibm.com>
cc: fweisbec@...il.com, paul.gortmaker@...driver.com, paulus@...ba.org,
shangw@...ux.vnet.ibm.com, rjw@...k.pl, paulmck@...ux.vnet.ibm.com,
arnd@...db.de, linux-pm@...r.kernel.org, rostedt@...dmis.org,
michael@...erman.id.au, john.stultz@...aro.org,
chenhui.zhao@...escale.com, deepthi@...ux.vnet.ibm.com,
r58472@...escale.com, geoff@...radead.org,
linux-kernel@...r.kernel.org, srivatsa.bhat@...ux.vnet.ibm.com,
schwidefsky@...ibm.com, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH V4 7/9] cpuidle/powernv: Add "Fast-Sleep" CPU idle
state
On Mon, 2 Dec 2013, Preeti U Murthy wrote:
> On 11/29/2013 08:09 PM, Thomas Gleixner wrote:
> > This supports HIGHRES and NO_HZ if done right, without polling at
> > all. So you can even let the last CPU which handles the broadcast
> > hrtimer go for a long sleep, just not in the deepest idle state.
>
> Thank you for the review. The above points are all valid. I will rework
> the design to:
>
> 1. Eliminate the concept of a broadcast CPU and integrate its
> functionality in the timekeeping CPU.
>
> 2. Avoid polling by using IPIs to communicate the next wakeup of the
> CPUs in deep idle state so as to reprogram the broadcast hrtimer.
>
> 3. Make this feature generic and not arch-specific.
Great. If you need help with the generic bits, please let me know.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists