[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200902041554.29184.nickpiggin@yahoo.com.au>
Date: Wed, 4 Feb 2009 15:54:27 +1100
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
andi@...stfloor.org, oleg@...hat.com, viro@...iv.linux.org.uk,
davidel@...ilserver.org, davem@...emloft.net, hch@....de,
linux-api@...r.kernel.org, mpm@...enic.com,
alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH 2/4] Convert epoll to a bitlock
On Wednesday 04 February 2009 08:39:42 Andrew Morton wrote:
> On Mon, 2 Feb 2009 11:20:09 -0700
>
> Jonathan Corbet <corbet@....net> wrote:
> > Matt Mackall suggested converting epoll's ep_lock to a bitlock as a way
> > of saving space in struct file. This patch makes that change.
>
> hrm. bit_spin_lock() makes people upset (large penguiny people). iirc
> it doesn't have all the correct/well-understood memory/compiler
> ordering semantics which spinlocks have.
Bit spinlocks are OK now they are using lock bitops. Of course, they are
even nicer (and become very comparable to spinlocks) if you can use the
non-atomic unlock __bit_spin_unlock().
But it seems probably like another approach being discussed is a better
idea anyway.
> And lockdep doesn't know about
> it.
This is a valid concern. Someone had a patch to add lockdep support to it,
which might be a good idea to do. But for small inner locks, maybe not a
huge problem.
--
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