Messages in this thread | | | Date | Wed, 18 Jan 2006 18:10:46 +0100 | From | Nick Piggin <> | Subject | Re: [patch 1/2] atomic_add_unless sadness |
| |
On Wed, Jan 18, 2006 at 08:48:01AM -0800, Linus Torvalds wrote: > > > On Wed, 18 Jan 2006, Nick Piggin wrote: > > > > For some reason gcc 4 on at least i386 and ppc64 (that I have tested with) > > emit two cmpxchges for atomic_add_unless unless we put branch hints in. > > (it is unlikely for the "unless" case to trigger, and it is unlikely for > > cmpxchg to fail). > > Irrelevant. If "atomic_add_unless()" is in a hot path and inlined, we're > doing something else wrong anyway. It's not a good op to use. Just think > of it as being very expensive. >
I don't think it is quite irrelevant. Regardless of where it is used, it doesn't hurt to make something smaller and more efficient.
> The _only_ user of "atomic_add_unless()" is "dec_and_lock()", which isn't > even inlined. The fact that gcc ends up "unrolling" the loop once is just > fine. >
dec_and_lock is not exactly a slow path. Maybe unrolling doesn't slow it down in the traditional sense, but you're the one (rightly, I gather) always talking about icache. In fact it unrolls an exceedingly rare second iteration into the main code path.
> Please keep it that way. >
fs/file_table.c uses it as well (inc_not_zero).
Nick
- 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/
| |