Re: Synchronizing Bit operations V2

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Fri, Mar 31, 2006 at 09:56:23AM -0800, Christoph Lameter wrote:
> On Fri, 31 Mar 2006, Andi Kleen wrote:
> 
> > > Powerpc can do similar things AFAIK. Not sure what other arches have 
> > > finer grained control over barriers but it could cover a lot of special 
> > > cases for other processors as well.
> > 
> > Yes, but I don't think the goal of a portable atomic operations API
> > in Linux is it to cover everybody's special case in every possible 
> > combination. The goal is to have an abstraction that will lead to 
> > portable code. I don't think your proposal will do this.
> 
> AFAIK The goal of a bitmap operations API (we are not talking about atomic 
> operations here) is to make bitmap operations as efficient as possible and 
> as simple as possible.

If we are not talking about atomic operations...

> We already have multiple special cases for each 
> bitmap operation
> 
> I.e.
> 
> clear_bit()

why do you then bring up the atomic bitop operation here?

> __clear_bit()

this is the non-atomic bitop operation.

> and some people talk abouit
> 
> clear_bit_lock()
> clear_bit_unlock()

Neither of these exist in the kernel.

> What I am prosing is to do one clear_bit_mode function that can take a 
> parameter customizing its synchronization behavior.
> 
> clear_bit_mode(bit,addr,mode)

Which means for architectures which implement bitops out of line (due
to their size) that you end up making those architectures even more
inefficient because they now have to decode the "mode" parameter which
will take several compares and branches.

The only way around that would be for such architectures to do:

#define clear_bit_mode(bit,addr,mode)	clear_bit_mode_##mode(bit,addr)

and then we're back to the named function approach.

Incidentally, you say that the named function approach is not extensible.
Do you have a limit on the number of functions you can have in your
kernel?  If not, I don't see where such a statement would come from -
you obviously can extend "clear_bit_atomic" and "clear_bit_nonatomic"
by adding eg, "clear_bit_barrier".  And if you really want to multiplex
them through one function, you can do:

#define clear_bit_atomic(bit,addr)	clear_bit_mode(bit,addr,MODE_ATOMIC)
#define clear_bit_nonatomic(bit,addr)	clear_bit_mode(bit,addr,MODE_NONATOMIC)
#define clear_bit_barrier(bit,addr)	clear_bit_mode(bit,addr,MODE_BARRIER)

etc.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/