* Andrew Morton <[email protected]> wrote:
> OK. That sucks. A sufficiently large machine with the right mix of
> latencies will get hit by the NMI watchdog in write_lock_irq().
>
> But presumably the situation is much worse with CONFIG_DEBUG_SPINLOCK
> because of that __delay().
>
> So how about we remove the __delay() (which is wrong anyway, because
> loops_per_jiffy isn't calculated with a write_trylock() in the loop
> (which means we're getting scarily close to the NMI watchdog at
> present)).
>
> Instead, calculate a custom loops_per_jiffy for this purpose in
> lib/spinlock_debug.c?
hm, that would be yet another calibration loop with the potential to be
wrong (and which would slow down the bootup process). If loops_per_jiffy
is wrong then our timings are toast anyway.
I think increasing the timeout to 60 secs ought to be enough - 1 sec was
a bit too close to valid delays and i can imagine really high loads
causing 1 sec delays (especially if something like SysRq-T is holding
the tasklist_lock for long).
The write_trylock + __delay in the loop is not a problem or a bug, as
the trylock will at most _increase_ the delay - and our goal is to not
have a false positive, not to be absolutely accurate about the
measurement here.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
