From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: deepthi@linux.vnet.ibm.com, shangw@linux.vnet.ibm.com,
arnd@arndb.de, linux-pm@vger.kernel.org, geoff@infradead.org,
Frederic Weisbecker <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org, rostedt@goodmis.org, rjw@sisk.pl,
paul.gortmaker@windriver.com, john.stultz@linaro.org,
srivatsa.bhat@linux.vnet.ibm.com, schwidefsky@de.ibm.com,
tglx@linutronix.de, paulmck@linux.vnet.ibm.com,
linuxppc-dev@lists.ozlabs.org, chenhui.zhao@freescale.com
Subject: Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
Date: Fri, 26 Jul 2013 09:05:44 +0530 [thread overview]
Message-ID: <51F1EE90.9020701@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130726031950.GA6438@iris.ozlabs.ibm.com>
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 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.
>>
>> Let me elaborate. The CPUs in deep idle states have their lapics
>> deactivated. This means the next timer event which would typically have
>> been taken care of by a lapic firing at the appropriate moment does not
>> get taken care of in deep idle states, due to the lapic being switched off.
>
> I really don't think it's helpful to use the term "lapic" in
> connection with Power systems. There is nothing that is called a
> "lapic" in a Power machine. The nearest equivalent of the LAPIC on
> x86 machines is the ICP, the interrupt-controller presentation
> element, of which there is one per CPU thread.
>
> However, I don't believe the ICP gets disabled in deep sleep modes.
> What does get disabled is the "decrementer", which is a register that
> normally counts down (at 512MHz) and generates an exception when it is
> negative. The decrementer *is* part of the CPU core, unlike the ICP.
> That's why we can still get IPIs but not timer interrupts.
>
> Please reword your patch description to not use the term "lapic",
> which is not defined in the Power context and is therefore just
> causing confusion.
Noted. Thank you :) I will probably send out a fresh patchset with the
appropriate changelog to avoid this confusion ?
>
> Paul.
>
Regards
Preeti U murthy
next prev parent reply other threads:[~2013-07-26 3:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 9:02 [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states Preeti U Murthy
2013-07-25 9:02 ` [RFC PATCH 1/5] powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC) Preeti U Murthy
2013-07-25 9:02 ` [RFC PATCH 2/5] powerpc: Implement broadcast timer interrupt as an IPI message Preeti U Murthy
2013-07-25 9:02 ` [RFC PATCH 3/5] cpuidle/ppc: Add timer offload framework to support deep idle states Preeti U Murthy
2013-07-25 9:03 ` [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints Preeti U Murthy
2013-07-25 13:30 ` Frederic Weisbecker
2013-07-26 2:39 ` Preeti U Murthy
2013-07-26 3:19 ` Paul Mackerras
2013-07-26 3:35 ` Preeti U Murthy [this message]
2013-07-26 4:11 ` Preeti U Murthy
2013-07-27 6:30 ` Benjamin Herrenschmidt
2013-07-27 7:50 ` Preeti U Murthy
2013-07-29 5:28 ` Vaidyanathan Srinivasan
2013-07-29 10:11 ` Preeti U Murthy
2013-07-29 5:11 ` Vaidyanathan Srinivasan
2013-07-26 3:03 ` Preeti U Murthy
2013-07-25 9:03 ` [RFC PATCH 5/5] cpuidle/ppc: Add longnap state to the idle states on powernv Preeti U Murthy
2013-07-26 10:05 ` [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states Li Yang-R58472
2013-07-26 13:11 ` Preeti U Murthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F1EE90.9020701@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=arnd@arndb.de \
--cc=chenhui.zhao@freescale.com \
--cc=deepthi@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=geoff@infradead.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paul.gortmaker@windriver.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=rjw@sisk.pl \
--cc=rostedt@goodmis.org \
--cc=schwidefsky@de.ibm.com \
--cc=shangw@linux.vnet.ibm.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).