From: Paul Mackerras <paulus@samba.org>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
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 13:19:50 +1000 [thread overview]
Message-ID: <20130726031950.GA6438@iris.ozlabs.ibm.com> (raw)
In-Reply-To: <51F1E15B.3050106@linux.vnet.ibm.com>
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.
Paul.
next prev parent reply other threads:[~2013-07-26 3:19 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 [this message]
2013-07-26 3:35 ` Preeti U Murthy
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=20130726031950.GA6438@iris.ozlabs.ibm.com \
--to=paulus@samba.org \
--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=preeti@linux.vnet.ibm.com \
--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).