From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: ccb@acm.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min
Date: Mon, 19 Jun 2006 10:12:52 +0200 [thread overview]
Message-ID: <20060619081252.GA13176@elte.hu> (raw)
In-Reply-To: <20060619005955.b05840e8.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org> wrote:
> On Mon, 19 Jun 2006 09:02:29 +0200
> Ingo Molnar <mingo@elte.hu> 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
next prev parent reply other threads:[~2006-06-19 8:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-12 19:53 BUG: write-lock lockup Charles C. Bennett, Jr.
2006-06-17 17:07 ` Andrew Morton
2006-06-19 7:02 ` [patch] increase spinlock-debug looping timeouts from 1 sec to 1 min Ingo Molnar
2006-06-19 7:59 ` Andrew Morton
2006-06-19 8:12 ` Ingo Molnar [this message]
2006-06-19 8:21 ` Ingo Molnar
2006-06-19 8:32 ` Andrew Morton
2006-06-19 8:35 ` Ingo Molnar
2006-06-19 9:13 ` Andrew Morton
2006-06-19 11:39 ` Ingo Molnar
2006-06-19 19:55 ` Andrew Morton
2006-06-20 8:06 ` Arjan van de Ven
2006-06-20 8:40 ` [patch] fix spinlock-debug looping Ingo Molnar
2006-06-20 8:52 ` Andrew Morton
2006-06-20 9:15 ` Ingo Molnar
2006-06-20 9:32 ` Andrew Morton
2006-06-20 9:34 ` Ingo Molnar
2006-06-20 16:02 ` Dave Olson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060619081252.GA13176@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=ccb@acm.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.