Messages in this thread | | | Date | Wed, 26 Apr 2006 11:56:02 +0200 | From | Jörn Engel <> | Subject | Re: [PATCH] Profile likely/unlikely macros |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |