From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
Chris Zankel <czankel@tensilica.com>,
linux-arch@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: Lots of possible arch breakage in cpu_idle!!
Date: Mon, 30 May 2005 21:49:08 +1000 [thread overview]
Message-ID: <429AFDB4.5090706@yahoo.com.au> (raw)
In-Reply-To: <OFB45EDFAC.AFFB6ECD-ONC1257011.003ED09F-C1257011.003F9081@de.ibm.com>
Martin Schwidefsky wrote:
>>>Well, currently there seems to be only the pfault interrupt that can
>>>set TIF_NEED_RESCHED and pfault interrupts can't happen for idle. So
>>>it should work. But if there is any chance that an interrupt will ever
>>>set TIF_NEED_RESCHED we have to disable the interrupts before doing
>>>the resched check.
>>
>>But other processors can set your TIF_NEED_RESCHED too,
>>so simply disabling local interrupts does not give any
>>synchronisation of TIF_NEED_RESCHED.
>
>
> But these other processors need to send the idle cpu an IPI to make it
> aware of the TIF_NEED_RESCHED bit. The order of events is important
> here. While the interrupts are disabled the IPI is pending, only after
> the enabled-wait psw has been loaded the IPI interrupts comes in.
>
Yep.
> After you threw in set_bit(TIF_NEED_RESCHED) from another processor
> I realized that without the local_irq_disable() the code would even be
> wrong. We can loose a reschedule without it, consider the following:
> cpu-a checks for reschedule, cpu-b sets TIF_NEED_RESCHED, cpu-b sends
> IPI, cpu-a receives IPI as external interrupt, cpu-a continues in
> default_idle() after the reschedule check. With the NO_IDLE_HZ option
> the cpu-a can now wait for a very long time until the next interrupt
> wakes it up again.
>
OK, thanks. I'll restore s390's behaviour in the next rev.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2005-05-30 11:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-29 5:25 Lots of possible arch breakage in cpu_idle!! Nick Piggin
2005-05-29 5:44 ` Andrew Morton
2005-05-29 8:45 ` William Lee Irwin III
2005-05-29 10:03 ` Nick Piggin
2005-05-29 10:13 ` William Lee Irwin III
2005-05-29 11:39 ` William Lee Irwin III
2005-05-29 9:42 ` William Lee Irwin III
2005-05-29 10:08 ` Nick Piggin
2005-05-29 10:14 ` William Lee Irwin III
2005-05-29 16:55 ` Richard Henderson
2005-05-29 20:41 ` David S. Miller
2005-05-29 20:56 ` Richard Henderson
2005-05-30 0:37 ` Nick Piggin
2005-05-30 11:01 ` Martin Schwidefsky
2005-05-30 11:18 ` Nick Piggin
2005-05-30 11:34 ` Martin Schwidefsky
2005-05-30 11:49 ` Nick Piggin [this message]
2005-05-31 8:56 ` David Howells
2005-05-31 9:02 ` Nick Piggin
2005-05-31 9:05 ` David Howells
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=429AFDB4.5090706@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=czankel@tensilica.com \
--cc=linux-arch@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=schwidefsky@de.ibm.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 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.