Message-ID: <4427B292.3080204@bull.net>
Date: Mon, 27 Mar 2006 11:38:26 +0200
From: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
MIME-Version: 1.0
To: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: unlock_buffer() and clear_bit()
References: <44247FAB.3040202@free.fr>	<20060325040233.1f95b30d.akpm@osdl.org>	<4427A817.4060905@bull.net> <20060327010739.027d410d.akpm@osdl.org>
In-Reply-To: <20060327010739.027d410d.akpm@osdl.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1313
Lines: 39

Andrew Morton wrote:

> This is, I think, a rather inefficient thing we're doing there.  For most
> architectures, that amounts to:
> 
> 	mb();
> 	clear_bit()
> 	mb();
> 
> which is probably more than is needed.  We'd need to get some other
> architecture people involved to see if there's a way of improving this, and
> unlock_page().

This is why I proposed also:

>>> Or a new bit clearing service needs to be added that includes
>>>   the "rel" semantics, say "release_N_clear_bit()"

The architecture dependent "release_N_clear_bit()" should include what
is necessary for the correct unlocking semantics (and it leaves the freedom
for the "stand alone" bit operations implementations).

Note that "lock_buffer()" works on ia64 "by chance", because all the
atomic bit operations are implemented "by chance" by use of the "acq"
semantics.

I'd like to split the bit operations according to their purposes:
- e.g. "test_and_set_bit_N_acquire()" for lock acquisition
- "test_and_set_bit()", "clear_bit()" as they are today
- "release_N_clear_bit()"...

Thaks,

Zoltan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/