From: Nick Piggin <nickpiggin@yahoo.com.au>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: linux-arch@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
David Mosberger <davidm@hpl.hp.com>
Subject: Re: Remaining arch problems in cpu_idle
Date: Thu, 30 Jun 2005 10:17:05 +1000 [thread overview]
Message-ID: <42C33A01.4000302@yahoo.com.au> (raw)
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F03D0B84D@scsmsx401.amr.corp.intel.com>
Luck, Tony wrote:
>>I don't suppose safe_halt can be called with interrupts off
>>safely, like the i386 function of the same name?
>
>
> Yes. Looking at the code for safe_halt() [chasing through
> ia64_do_halt_light() to PAL_CALL() to ia64_pal_call_static] I see
> that we disable interrupts before calling into the PAL, and restore
> the state after we return. So somewhere in the depths of the PAL
> code the cpu is checking to see whether an external interrupt is
> pending, even though we have interrupts blocked.
>
OK, in which case we should be able to disable interrupts before
checking need_resched() ?
Something like the following:
void
default_idle (void)
{
- while (!need_resched())
- if (can_do_pal_halt)
- safe_halt();
- else
+ if (can_do_pal_halt) {
+ while (!need_resched()) {
+ local_irq_disable();
+ if (!need_resched())
+ safe_halt();
+ local_irq_enable();
+ } else {
+ while (!need_resched())
cpu_relax();
+ }
}
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2005-06-30 0:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-30 0:07 Remaining arch problems in cpu_idle Luck, Tony
2005-06-30 0:17 ` Nick Piggin [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-06-29 23:46 Luck, Tony
2005-06-29 23:55 ` Nick Piggin
2005-06-29 21:51 Luck, Tony
2005-06-29 23:38 ` Nick Piggin
2005-06-29 7:06 Nick Piggin
2005-06-29 8:00 ` Paul Mundt
2005-06-29 9:09 ` Nick Piggin
2005-06-29 10:11 ` Paul Mundt
2005-06-29 10:20 ` Nick Piggin
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=42C33A01.4000302@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=davidm@hpl.hp.com \
--cc=linux-arch@vger.kernel.org \
--cc=tony.luck@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