Re: test_and_set_bit implementation

[Zoltan Menyhart <Zoltan.Menyhart@bull.net>]

Christoph Lameter wrote:

>>How much is the probability that the bit is not set?

> Depends on the load on the system. Typically very much near 100%

If you are right, why do we need "bit_spin_lock()" that much complicated?

       while (test_and_set_bit(bitnum, addr)) {
               while (test_bit(bitnum, addr)) {
                       preempt_enable();
                       cpu_relax();
                       preempt_disable();
               }
       } 

If "test_and_set_bit()" did not modify the lock while it's busy, a
simpler solution would do:

       while (test_and_set_bit(bitnum, addr)) {
               preempt_enable();
               cpu_relax();
               preempt_disable();
       } 

>>Adding a test can cost only a few cycles, say max 4.
> 
> But it reduces the performance of the commonly taken code path.
...
>>
>>By executing the atomic operation unconditionally, you kill
>>the cache line all the other waiting processors looping at.
> 
> But note also that we optimize the common case, the case that the test and 
> set bit are successful. Only if it was not successful will we do non 
> atomic loads. This is done to avoid cachelines bouncing while the lock is 
> contended.

I can accept these arguments for small, not too much busy systems.

As the snooping and the cache line bouncing costs increases quadratically
with the system size...

Have you got some lock benchmarks to measure it?

Thanks,

Zoltán Menyhárt