Re: [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min
From: Ingo Molnar
Date: Mon Jun 19 2006 - 04:16:31 EST
* 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, it's only debug code. But RH (for one) have decided to ship
> zillions of kernels with this debug code turned on.
yes - Fedora enables most of the transparent kernel debugging options
(slab, lock debugging) in rawhide. The current list is:
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_RODATA=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
Ingo
-
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/