public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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