All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: cpu_idle and cpu_wait
Date: Wed, 16 Nov 2005 18:42:01 +0000	[thread overview]
Message-ID: <20051116184201.GJ3229@linux-mips.org> (raw)
In-Reply-To: <20051117.011906.25910026.anemo@mba.ocn.ne.jp>

On Thu, Nov 17, 2005 at 01:19:06AM +0900, Atsushi Nemoto wrote:

> Looking at recent change in cpu_idle(), I find an another potential
> problem with cpu_wait (WAIT instruction).
> 
>     48	ATTRIB_NORET void cpu_idle(void)
>     49	{
>     50		/* endless idle loop with no priority at all */
>     51		while (1) {
>     52			while (!need_resched())
>     53				if (cpu_wait)
>     54					(*cpu_wait)();
>     55			preempt_enable_no_resched();
>     56			schedule();
>     57			preempt_disable();
>     58		}
>     59	}
> 
> If an interrupt raised on line 53 and the interrupt handler woke a
> sleeping thread up, the thread becomes runnable and current thread
> (idle thread) is marked as NEED_RESCHED.
> 
> Since preemption is disabled, the interrupt handler just return to
> current thread (idle thread) without rescheduling.  The idle thread
> then call cpu_wait() and execute WAIT instruction (or something
> similer).  The CPU will stops until next interrupt.  Then the idle
> task checks need_resched() and finally calls schedule().  Therefore,
> wakeup-resume latency will be nearly one TICK on worst case!

Pleassure.

> If this analysis was correct, how to fix this?
> 
> Removing above preempt_enable_no_resched/preempt_disable pair would
> fix it for preemptive kernel, but no point for non-preemptive kernel.
> Replacing them with local_irq_enable/local_irq_disable would fix it
> for both kernel, but there is an question:

Somebody sneaking those lines into kernel.org ...

> 	The CPU can surely exit from the WAIT instruction by interrupt
> 	even if interrupts disabled?

That's implementation dependent behaviour, unfortunately.

  Ralf

  reply	other threads:[~2005-11-16 18:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-16 16:19 cpu_idle and cpu_wait Atsushi Nemoto
2005-11-16 18:42 ` Ralf Baechle [this message]
2005-11-17  2:21   ` Atsushi Nemoto
2005-11-17  7:08     ` Atsushi Nemoto
2005-11-18  3:22   ` Atsushi Nemoto
2006-06-07 16:09     ` Atsushi Nemoto
2006-09-10  0:18       ` Ralf Baechle
2006-09-10 12:52         ` Atsushi Nemoto

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=20051116184201.GJ3229@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=linux-mips@linux-mips.org \
    /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.