Hi,
On 07/29/2013 10:58 AM, Vaidyanathan Srinivasan wrote:
* Preeti U Murthy pre...@linux.vnet.ibm.com [2013-07-27 13:20:37]:
Hi Ben,
On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
*The lapic of a broadcast CPU is active
* Benjamin Herrenschmidt b...@kernel.crashing.org [2013-07-27 16:30:05]:
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
*The lapic of a broadcast CPU is active always*. Say CPUX, wants the
broadcast CPU to wake it up at timeX. Since we cannot program the lapic
of a remote CPU,
* Preeti U Murthy pre...@linux.vnet.ibm.com [2013-07-27 13:20:37]:
Hi Ben,
On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
*The lapic of a broadcast CPU is active always*. Say CPUX, wants the
broadcast CPU to wake it up at
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
*The lapic of a broadcast CPU is active always*. Say CPUX, wants the
broadcast CPU to wake it up at timeX. Since we cannot program the lapic
of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
asking it to program its
Hi Ben,
On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
*The lapic of a broadcast CPU is active always*. Say CPUX, wants the
broadcast CPU to wake it up at timeX. Since we cannot program the lapic
of a remote CPU, CPUX will need
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
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
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.
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.
On Fri, Jul 26, 2013 at 08:09:23AM +0530, Preeti U Murthy wrote:
Hi Frederic,
On 07/25/2013 07:00 PM, Frederic Weisbecker wrote:
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
Hi Paul,
On 07/26/2013 08:49 AM, Paul Mackerras wrote:
On Fri, Jul 26, 2013 at 08:09:23AM +0530, Preeti U Murthy wrote:
Hi Frederic,
On 07/25/2013 07:00 PM, Frederic Weisbecker wrote:
Hi Preeti,
I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle
mode.
I read in
Hi Frederic,
I apologise for the confusion. As Paul pointed out maybe the usage of
the term lapic is causing a large amount of confusion. So please see the
clarification below. Maybe it will help answer your question.
On 07/26/2013 08:09 AM, Preeti U Murthy wrote:
Hi Frederic,
On 07/25/2013
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
decrementer of the broadcast cpu for their respective next
13 matches
Mail list logo
