Re: rcuref optimization

[Nick Piggin]

Joe Seigh wrote:
> You can get rid of the requirement for atomic_inc_not_zero logic
> if you use the logic I first proposed here in c.l.c++.m.
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=3E7C83DD.B126DE24%40xemaps.com 
>
> for weakptrs where the same kind of logic was required for the strong 
> count.
> This will allow you to use fetch_inc (e.g. LOCK INC on x86) instead of 
> compare
> and swap logic which might be more efficient on some processors.  You might
> even be able to get rid of the the "unincrement" if you are pretty sure the
> maximum number of increments won't put the refcount to zero.
>
> Summary for those who can't follow the link.  Basically, if you 
> decrement the
> refcount to zero, you attempt to set the refcount to the minimum signed 
> value
> (e.g. 0x80000000 for 32 bits).  If successful you can schedule the object
> for deallocation using RCU.  If unsuccessful, some other thread has 
> incremented
> the refcount and object is still in use and even deallocated by some 
> other thread.
> Incrementing of the refcount is only considered successful if the result 
> is greater
> than zero.  If less than zero, object is being scheduled for deallocation.

Clever idea.

I don't know... atomic_inc_not_zero is implemented very easily on the
many architectures without SMP, and I think it *could* be implemented
very nicely on ll/sc based architectures without using cmpxchg.

Lastly, your InterlockedIncrement and InterlockedDecrement are not
actually atomic_inc (LOCK INC), but atomic_inc_return (XADD). Another
primitive like atomic_inc_return_negative or something could be added
to take advantages of status flags and use LOCK INC, but this will
probably not be worthwhile for any architecture other than i386/x86-64
(ie. it will be plain worse on most ll/sc and UP-only architectures
once they get around to implementing atomic_inc_not_zero properly)

Also, the extra logic and atomic op in the decrement-to-zero case
takes a bit of shine off it even for i386. I'd say we should stick
to what we have unless we see some really compelling numbers.

Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/