Re: [PATCH] Profile likely/unlikely macros

[Jörn Engel]

On Wed, 26 April 2006 11:08:09 +1000, Nick Piggin wrote:
> Daniel Walker wrote:
> 
> Ah, I see. Then you should be OK with either your current scheme, or
> Andrew's suggestion, so long as you have a memory barrier before the
> unlock (eg. smp_mb__before_clear_bit()).
> 
> >I'm not exactly sure what you mean by "release consistency" ?
> 
> Without a barrier, the stores to the linked list may be visible to another
> CPU after the store that unlocks the atomic_t. Ie. the critical section can
> leak out of the lock.

Admitted, I'm a bit slow at times.  But why does this matter?
According to my fairly limited brain, you take a potentially expensive
barrier, so you pay with a bit of runtime.  What you buy is a smaller
critical section, so you can save some runtime on other cpus.  When
optimizing for the common case, which is one cpu, this is a net loss.

There must be some correctness issue hidden that I cannot see.  Can
you explain that to me?

Jörn

-- 
A victorious army first wins and then seeks battle.
-- Sun Tzu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/