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

[Andrew Morton]

On Mon, 19 Jun 2006 10:12:52 +0200
Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * Andrew Morton <akpm@xxxxxxxx> wrote:
> 
> > On Mon, 19 Jun 2006 09:02:29 +0200
> > Ingo Molnar <mingo@xxxxxxx> wrote:
> > 
> > > Subject: increase spinlock-debug looping timeouts from 1 sec to 1 
> > > min
> > 
> > But it's broken.  In the non-debug case we subtract RW_LOCK_BIAS so we 
> > know that the writer will get the lock when all readers vacate.  But 
> > in the CONFIG_DEBUG_SPINLOCK case we don't do that, with the result 
> > that taking a write_lock can take over a second.
> > 
> > A much, much better fix (which involves visiting all architectures) 
> > would be to subtract RW_LOCK_BIAS and _then_ wait for a second.
> 
> no. Write-locks are unfair too, and there's no guarantee that writes are 
> listened to. That's why nested read_lock() is valid, while nested 
> down_read() is invalid.
> 
> Take a look at arch/i386/kernel/semaphore.c, __write_lock_failed() just 
> adds back the RW_LOCK_BIAS and retries in a loop. There's no difference 
> to an open-coded write_trylock loop - unless i'm missing something 
> fundamental.

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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/