From: Jamie Lokier <jamie@shareable.org>
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, "Saxena,
Sunil" <sunil.saxena@intel.com>,
"Mallick, Asit K" <asit.k.mallick@intel.com>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Subject: Re: [PATCH] idle using PNI monitor/mwait (take 2)
Date: Sat, 6 Sep 2003 10:58:12 +0100 [thread overview]
Message-ID: <20030906095812.GA9796@mail.jlokier.co.uk> (raw)
In-Reply-To: <7F740D512C7C1046AB53446D3720017304A72D@scsmsx402.sc.intel.com>
Nakajima, Jun wrote:
> > The result is a halted CPU even though need_resched is set, and the
> > idle loop isn't broken until the next interrupt, often a timer tick.
>
> I'm aware of the window, but did not realize that it could cause high
> latency spikes. Is that still the case with 2.6 where we have higher HZ
> (1000)? Anyway, I think it's a cheap way of removing such spikes.
HZ is irrelevant. If you receive an interrupt, and typical wakeup
latency is 0.05ms, then waiting until the next timer tick in 1ms is a spike.
Some applications tolerate that, some don't.
> > So you can remove it from your loop.
> Okay we'll remove local_irq_enable() at entry. So in that case we can
> remove the local_irq_enable() below as well?
>
> static void poll_idle (void)
> {
> int oldval;
>
> => local_irq_enable();
I misunderstood you and now you misunderstood me :)
It's ok to _disable_ irqs for the reasons I gave. I thought of that
because you pointed to the _disable_ in your quote of default_idle.
The _enable_ is there for a different reason.
Scheduling is not allowed with interrupts disabled. So we know that
when schedule() returns, local irqs are enabled. So poll_idle() doesn't
need to enable them. I suggest this change:
- remove the local_irq_enable() from poll_idle().
- add local_irq_enable() at the start of cpu_idle(), before the loop.
-- Jamie
diff -urN --exclude-from=dontdiff orig-2.6.0-test4/arch/i386/kernel/process.c idle_irqs-2.6.0-test4/arch/i386/kernel/process.c
--- orig-2.6.0-test4/arch/i386/kernel/process.c 2003-09-02 23:05:06.000000000 +0100
+++ idle_irqs-2.6.0-test4/arch/i386/kernel/process.c 2003-09-06 10:50:59.000000000 +0100
@@ -105,8 +105,6 @@
{
int oldval;
- local_irq_enable();
-
/*
* Deal with another CPU just having chosen a thread to
* run here:
@@ -136,6 +134,8 @@
*/
void cpu_idle (void)
{
+ local_irq_enable();
+
/* endless idle loop with no priority at all */
while (1) {
while (!need_resched()) {
next prev parent reply other threads:[~2003-09-06 9:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-06 1:03 [PATCH] idle using PNI monitor/mwait (take 2) Nakajima, Jun
2003-09-06 9:58 ` Jamie Lokier [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-09-05 20:41 Nakajima, Jun
2003-09-05 21:14 ` Jamie Lokier
2003-09-05 22:03 ` Jamie Lokier
2003-09-05 2:19 Nakajima, Jun
2003-09-05 17:14 ` Andrew Morton
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=20030906095812.GA9796@mail.jlokier.co.uk \
--to=jamie@shareable.org \
--cc=akpm@osdl.org \
--cc=asit.k.mallick@intel.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sunil.saxena@intel.com \
--cc=venkatesh.pallipadi@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 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).