From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: linaro-kernel@lists.linaro.org,
Russell King <linux@arm.linux.org.uk>,
linux-pm@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, Paul Mundt <lethal@linux-sh.org>,
linux-sh@vger.kernel.org, Olof Johansson <olof@lixom.net>,
Thomas Gleixner <tglx@linutronix.de>,
linuxppc-dev@lists.ozlabs.org, Ingo Molnar <mingo@redhat.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
Date: Thu, 30 Jan 2014 09:08:46 +0530 [thread overview]
Message-ID: <52E9C946.50704@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1401291526320.1652@knanqh.ubzr>
Hi Nicolas,
On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
> On Wed, 29 Jan 2014, Nicolas Pitre wrote:
>
>> In order to integrate cpuidle with the scheduler, we must have a better
>> proximity in the core code with what cpuidle is doing and not delegate
>> such interaction to arch code.
>>
>> Architectures implementing arch_cpu_idle() should simply enter
>> a cheap idle mode in the absence of a proper cpuidle driver.
>>
>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> As mentioned in my reply to Olof's comment on patch #5/6, here's a new
> version of this patch adding the safety local_irq_enable() to the core
> code.
>
> ----- >8
>
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
> Subject: idle: move the cpuidle entry point to the generic idle loop
>
> In order to integrate cpuidle with the scheduler, we must have a better
> proximity in the core code with what cpuidle is doing and not delegate
> such interaction to arch code.
>
> Architectures implementing arch_cpu_idle() should simply enter
> a cheap idle mode in the absence of a proper cpuidle driver.
>
> In both cases i.e. whether it is a cpuidle driver or the default
> arch_cpu_idle(), the calling convention expects IRQs to be disabled
> on entry and enabled on exit. There is a warning in place already but
> let's add a forced IRQ enable here as well. This will allow for
> removing the forced IRQ enable some implementations do locally and
Why would this patch allow for removing the forced IRQ enable that are
being done on some archs in arch_cpu_idle()? Isn't this patch expecting
the default arch_cpu_idle() to have re-enabled the interrupts after
exiting from the default idle state? Its supposed to only catch faulty
cpuidle drivers that haven't enabled IRQs on exit from idle state but
are expected to have done so, isn't it?
Thanks
Regards
Preeti U Murthy
> allowing for the warning to trig.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/kernel/cpu/idle.c b/kernel/cpu/idle.c
> index 988573a9a3..14ca43430a 100644
> --- a/kernel/cpu/idle.c
> +++ b/kernel/cpu/idle.c
> @@ -3,6 +3,7 @@
> */
> #include <linux/sched.h>
> #include <linux/cpu.h>
> +#include <linux/cpuidle.h>
> #include <linux/tick.h>
> #include <linux/mm.h>
> #include <linux/stackprotector.h>
> @@ -95,8 +96,10 @@ static void cpu_idle_loop(void)
> if (!current_clr_polling_and_test()) {
> stop_critical_timings();
> rcu_idle_enter();
> - arch_cpu_idle();
> - WARN_ON_ONCE(irqs_disabled());
> + if (cpuidle_idle_call())
> + arch_cpu_idle();
> + if (WARN_ON_ONCE(irqs_disabled()))
> + local_irq_enable();
> rcu_idle_exit();
> start_critical_timings();
> } else {
>
next prev parent reply other threads:[~2014-01-30 3:42 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 17:45 [PATCH v2 0/6] setting the table for integration of cpuidle with the scheduler Nicolas Pitre
2014-01-29 17:45 ` [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop Nicolas Pitre
2014-01-29 20:31 ` Nicolas Pitre
2014-01-30 3:38 ` Preeti U Murthy [this message]
2014-01-30 5:28 ` Nicolas Pitre
2014-01-30 5:50 ` Preeti U Murthy
2014-01-30 13:44 ` Daniel Lezcano
2014-01-30 16:07 ` Nicolas Pitre
2014-01-30 17:28 ` Daniel Lezcano
2014-01-30 18:06 ` Peter Zijlstra
2014-01-30 19:24 ` Nicolas Pitre
2014-01-29 17:45 ` [PATCH v2 2/6] ARM: remove redundant cpuidle_idle_call() Nicolas Pitre
2014-01-29 17:45 ` [PATCH v2 3/6] PPC: " Nicolas Pitre
2014-01-29 17:45 ` [PATCH v2 4/6] SH: " Nicolas Pitre
2014-01-29 17:45 ` [PATCH v2 5/6] X86: " Nicolas Pitre
2014-01-29 19:02 ` Olof Johansson
2014-01-29 20:14 ` Nicolas Pitre
2014-01-30 9:24 ` Peter Zijlstra
2014-01-29 17:45 ` [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c Nicolas Pitre
2014-01-30 15:25 ` Peter Zijlstra
2014-01-30 16:03 ` Nicolas Pitre
2014-01-30 16:27 ` Peter Zijlstra
2014-01-30 16:41 ` Joe Perches
2014-01-30 16:52 ` Peter Zijlstra
2014-02-06 14:09 ` Nicolas Pitre
2014-02-06 16:43 ` Peter Zijlstra
2014-02-07 11:09 ` Nicolas Pitre
2014-02-07 12:32 ` Peter Zijlstra
2014-01-30 9:28 ` [PATCH v2 0/6] setting the table for integration of cpuidle with the scheduler Peter Zijlstra
2014-01-30 13:31 ` Nicolas Pitre
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=52E9C946.50704@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=daniel.lezcano@linaro.org \
--cc=lethal@linux-sh.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=nicolas.pitre@linaro.org \
--cc=olof@lixom.net \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--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).