All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jonathan Corbet <corbet@lwn.net>, John Kacur <jkacur@redhat.com>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vincent^M^J Sanders <vince@simtec.co.uk>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] sound_core.c: Remove BKL from soundcore_open
Date: Sun, 11 Oct 2009 12:26:32 -0700	[thread overview]
Message-ID: <20091011122632.53a61a09@infradead.org> (raw)
In-Reply-To: <20091011201759.435cd93c@lxorguk.ukuu.org.uk>

On Sun, 11 Oct 2009 20:17:59 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > it's getting time though to bite the bullet and make it a real
> > normal mutex. Lockdep will then flag a bunch of sh*t we'll need to
> > fix, but without doing that we're never going to really make
> > progress. 
> 
> It won't. Instead you get situations like one ioctl blocking another
> to an unrelated device that just causes weird failures and performance
> problems, or in some cases deadlocks.

yes the bkl using code will be slower because it'll now hit contention.

The deadlocks we need to catch imo; those are the behaviors that are
the worst offenders in terms of BKL weird behavior.

> 
> Open routines block so it takes about 5 seconds of thought to realise
> that using a mutex here is brain dead and doesn't work.

it also takes 5 seconds to realize "uh oh. they block. BKL is rather
limited in what it provides".


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  reply	other threads:[~2009-10-11 19:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-10 23:24 [PATCH] sound_core.c: Remove BKL from soundcore_open John Kacur
2009-10-10 23:42 ` Alan Cox
2009-10-11  0:25   ` John Kacur
2009-10-11 11:33     ` Frederic Weisbecker
2009-10-11 12:41       ` John Kacur
2009-10-11 14:12         ` Oliver Neukum
2009-10-11 20:40           ` Frederic Weisbecker
2009-10-11 21:25         ` John Kacur
2009-10-12  6:05         ` Takashi Iwai
2009-10-12  8:37           ` John Kacur
2009-10-12 10:17             ` Takashi Iwai
2009-10-12 10:42               ` John Kacur
2009-10-11 15:20     ` Jonathan Corbet
2009-10-11 17:15       ` Jonathan Corbet
2009-10-11 17:37         ` Arjan van de Ven
2009-10-11 19:17           ` Alan Cox
2009-10-11 19:26             ` Arjan van de Ven [this message]
2009-10-11 20:51               ` Alan Cox

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=20091011122632.53a61a09@infradead.org \
    --to=arjan@infradead.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=corbet@lwn.net \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=jkacur@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=vince@simtec.co.uk \
    /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.