[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091011122632.53a61a09@infradead.org>
Date: Sun, 11 Oct 2009 12:26:32 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Jonathan Corbet <corbet@....net>, John Kacur <jkacur@...hat.com>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Frederic Weisbecker <fweisbec@...il.com>,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Vincent^M^J Sanders <vince@...tec.co.uk>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sound_core.c: Remove BKL from soundcore_open
On Sun, 11 Oct 2009 20:17:59 +0100
Alan Cox <alan@...rguk.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists