Re: [patch 1/2] atomic_add_unless sadness

[Nick Piggin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/