Re: 'global' rq->clock

[Ingo Molnar <mingo@elte.hu>]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> On Sat, 2008-05-03 at 12:27 -0700, David Miller wrote:
> > > ( although please note that the growing generalization that goes on
> > >   _did_ find a subtle nohz problem on sparc64 early in the merge
> > window,
> > >   so it's not like these changes are totally useless to you. )
> > 
> > Note that this bug theoretically exists on every platform, even x86, 
> > and only sparc64 is fixed at the moment by adding the 
> > irq_{entry,exit}() guards around all of it's IPI handlers.
> 
> What is the bug ?
> 
> IPIs on power are normal interrupts, so they do happen in 
> irq_entry/exit blocks but I'm curious to know what the root bug is :-)

on nohz we still keep jiffies uptodate - despite there not being an 
explicit 'keep jiffies uptodate' tick interrupt anymore. So on every 
irq_enter() we roll jiffies forward - if needed - and thus emulate 
jiffies behavior to drivers and core kernel code, etc.

if an IPI on Power does not do an irq_enter() then you might miss out on 
updated jiffies. That might not matter for most jiffies, but you might 
also miss out on the 'touch the softlockup watchdog because we just woke 
from idle' action. This is what triggered the false positive warnings on 
Sparc64.

the same bug existed on x86 too: that too does a few IPIs without 
irq_enter/irq_exit. We now removed the softlockup dependency so it 
should not be required to do an irq_enter()/exit anymore - unless the 
code that the IPI uses accesses jiffies. (but that would be unusual)

	Ingo