From: Paul Mundt <lethal@linux-sh.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: linux-arch@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: Remaining arch problems in cpu_idle
Date: Wed, 29 Jun 2005 13:11:45 +0300 [thread overview]
Message-ID: <20050629101145.GB2694@linux-sh.org> (raw)
In-Reply-To: <42C26552.5020304@yahoo.com.au>
[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]
On Wed, Jun 29, 2005 at 07:09:38PM +1000, Nick Piggin wrote:
> Well you only need to disable IRQs if you are about to go to
> sleep waiting for the next pending IRQ. So your hlt_counter
> case looks OK.
>
> In the case that you do sleep until the next IRQ, sh64 does indeed
> disable irqs over the need_resched check, however it re-enables them
> before sleeping. So disabling at all is basically useless because
> any pending IRQs will probably all get serviced right as soon as IRQs
> are re-eanbled.
>
Ok, I've switched sh64 to use a similar model as sh.
> Well as you probably know, but just to be clear: architectures
> that handle this without a race have an instruction that basically
> turns on interrupts and go to sleep at the same time. I'm not aware
> of a simple way to do it without that facility.
>
> Unless you can easily raise an NMI from another processor as an IPI.
>
Unfortunately we don't have any such easy facility. The closest I suppose
would to have the watchdog generate an NMI, but that severely limits the
kind of sleep state that we are able to enter.
> As far as spin waiting goes, something like:
>
> while (!need_resched())
> cpu_relax();
>
> Is generally used.
>
> Now this might introduce some power and heat penalty. What's more,
> your race isn't a fatal one: in the worst case, it should just
> stall until the next timer interrupt (aside, that might be fatal
> with a tickless kernel).
>
After incorporating your changes, how about this?
--
diff --git a/arch/sh64/kernel/process.c b/arch/sh64/kernel/process.c
--- a/arch/sh64/kernel/process.c
+++ b/arch/sh64/kernel/process.c
@@ -305,44 +305,29 @@ static int __init hlt_setup(char *__unus
__setup("nohlt", nohlt_setup);
__setup("hlt", hlt_setup);
-static inline void hlt(void)
-{
- if (hlt_counter)
- return;
-
- __asm__ __volatile__ ("sleep" : : : "memory");
-}
-
/*
* The idle loop on a uniprocessor SH..
*/
-void default_idle(void)
+void cpu_idle(void)
{
/* endless idle loop with no priority at all */
while (1) {
if (hlt_counter) {
- while (1)
- if (need_resched())
- break;
+ while (!need_resched())
+ cpu_relax();
} else {
- local_irq_disable();
while (!need_resched()) {
- local_irq_enable();
idle_trace();
- hlt();
- local_irq_disable();
+ cpu_sleep();
}
- local_irq_enable();
}
+
+ preempt_enable_no_resched();
schedule();
+ preempt_disable();
}
}
-void cpu_idle(void)
-{
- default_idle();
-}
-
void machine_restart(char * __unused)
{
extern void phys_stext(void);
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-06-29 10:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-29 7:06 Remaining arch problems in cpu_idle Nick Piggin
2005-06-29 8:00 ` Paul Mundt
2005-06-29 9:09 ` Nick Piggin
2005-06-29 10:11 ` Paul Mundt [this message]
2005-06-29 10:20 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2005-06-29 21:51 Luck, Tony
2005-06-29 23:38 ` Nick Piggin
2005-06-29 23:46 Luck, Tony
2005-06-29 23:55 ` Nick Piggin
2005-06-30 0:07 Luck, Tony
2005-06-30 0:17 ` 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=20050629101145.GB2694@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=akpm@osdl.org \
--cc=linux-arch@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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