lkml.org 
[lkml]   [2008]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 'global' rq->clock

* 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


\
 
 \ /
  Last update: 2008-05-04 00:41    [W:0.079 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site