Re: [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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]
  Powered by Linux