From: Peter Zijlstra <peterz@infradead.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Chuansheng Liu <chuansheng.liu@intel.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
changcheng.liu@intel.com, xiaoming.wang@intel.com,
souvik.k.chakravarty@intel.com
Subject: Re: [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS back to DEFAULT
Date: Thu, 14 Aug 2014 14:41:35 +0200 [thread overview]
Message-ID: <20140814124135.GJ16043@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <53EC9A29.8090408@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
On Thu, Aug 14, 2014 at 01:14:49PM +0200, Daniel Lezcano wrote:
> On 08/14/2014 01:00 PM, Peter Zijlstra wrote:
> >On Thu, Aug 14, 2014 at 12:29:32PM +0200, Daniel Lezcano wrote:
> >>Hi Chuansheng,
> >>
> >>On 14 August 2014 04:11, Chuansheng Liu <chuansheng.liu@intel.com> wrote:
> >>
> >>>We found sometimes even after we let PM_QOS back to DEFAULT,
> >>>the CPU still stuck at C0 for 2-3s, don't do the new suitable C-state
> >>>selection immediately after received the IPI interrupt.
> >>>
> >>>The code model is simply like below:
> >>>{
> >>> pm_qos_update_request(&pm_qos, C1 - 1);
> >>> < == Here keep all cores at C0
> >>> ...;
> >>> pm_qos_update_request(&pm_qos, PM_QOS_DEFAULT_VALUE);
> >>> < == Here some cores still stuck at C0 for 2-3s
> >>>}
> >>>
> >>>The reason is when pm_qos come back to DEFAULT, there is IPI interrupt to
> >>>wake up the core, but when core is in poll idle state, the IPI interrupt
> >>>can not break the polling loop.
> >
> >So seeing how you're from @intel.com I'm assuming you're using x86 here.
> >
> >I'm not seeing how this can be possible, MWAIT is interrupted by IPIs
> >just fine, which means we'll fall out of the cpuidle_enter(), which
> >means we'll cpuidle_reflect(), and then leave cpuidle_idle_call().
> >
> >It will indeed not leave the cpu_idle_loop() function and go right back
> >into cpuidle_idle_call(), but that will then call cpuidle_select() which
> >should pick a new C state.
> >
> >So the interrupt _should_ work. If it doesn't you need to explain why.
>
> I think the issue is related to the poll_idle state, in
> drivers/cpuidle/driver.c. This state is x86 specific and inserted in the
> cpuidle table as the state 0 (POLL). There is no mwait for this state. It is
> a bit confusing because this state is not listed in the acpi / intel idle
> driver but inserted implicitly at the beginning of the idle table by the
> cpuidle framework when the driver is registered.
>
> static int poll_idle(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index)
> {
> local_irq_enable();
> if (!current_set_polling_and_test()) {
> while (!need_resched())
> cpu_relax();
> }
> current_clr_polling();
>
> return index;
> }
Ah, well, in that case there's a ton more broken than just this.
kick_all_cpus_sync() won't work either, and cpuidle_reflect() pretty
much expects to be called after each interrupt.
Then again, not reflecting properly isn't really a problem, its not like
not accounting interrupts is going to safe power much.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-08-14 12:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-14 2:11 [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS back to DEFAULT Chuansheng Liu
[not found] ` <CAKnoXLw3DrBAxCUWEkXtvCTf+E1w0xTHJSiSUY6Qd6xHXeGaoQ@mail.gmail.com>
2014-08-14 10:53 ` Peter Zijlstra
2014-08-14 11:24 ` Liu, Chuansheng
2014-08-14 13:13 ` Peter Zijlstra
2014-08-14 14:10 ` Liu, Chuansheng
2014-08-14 14:17 ` Daniel Lezcano
2014-08-14 14:26 ` Liu, Chuansheng
2014-08-14 14:26 ` Liu, Chuansheng
2014-08-14 11:00 ` Peter Zijlstra
2014-08-14 11:14 ` Daniel Lezcano
2014-08-14 11:17 ` Liu, Chuansheng
2014-08-14 11:17 ` Liu, Chuansheng
2014-08-14 12:41 ` Peter Zijlstra [this message]
2014-08-14 13:29 ` Daniel Lezcano
2014-08-14 13:57 ` Liu, Chuansheng
2014-08-14 13:57 ` Liu, Chuansheng
2014-08-14 21:12 ` Andy Lutomirski
2014-08-14 21:16 ` Peter Zijlstra
2014-08-14 21:22 ` Andy Lutomirski
2014-08-15 1:21 ` Liu, Chuansheng
2014-08-15 1:21 ` Liu, Chuansheng
2014-08-15 1:27 ` Andy Lutomirski
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=20140814124135.GJ16043@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=changcheng.liu@intel.com \
--cc=chuansheng.liu@intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=souvik.k.chakravarty@intel.com \
--cc=xiaoming.wang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.