Paul Mundt wrote:
On Wed, Jun 29, 2005 at 05:06:28PM +1000, Nick Piggin wrote:
h8300, ia64, and sh64 still have possible outstanding issues,
which I've put at the end of the Documentation/ file. It
would be nice to get these looked at.
Looking at this, sh64 is pretty much in the same category as h8300. sh
is as well, but we seem to be missing the local_irq_disable/enable around
the need_resched check there completely, which is even more bogus.
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.
+
+h8300 - Is such sleeping racy vs interrupts? (See #4a).
+ The H8/300 manual I found indicates yes, however disabling IRQs
+ over the sleep mean only NMIs can wake it up, so can't fix easily
+ without doing spin waiting.
+
We have the same problem for sh/sh64 (which isn't surprising, considering
they all share ancestry).
There are several different states that can be entered, with different
method for exiting, although at least the sleep and deep sleep states
both require an interrupt, NMI, or a reset request.
I can update sh and sh64 to follow the h8300 change, but that still
doesn't address the race. What sort of spin waiting do you have in mind?
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.
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).
So you may want a bootup or runtime switchable parameter there to
choose between good power saving and optimal performance &
scheduling latency.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
