To: linux-kernel@vger.kernel.org
From: Joe Seigh <jseigh_02@xemaps.com>
Subject: rcuref optimization
Date: Wed, 21 Dec 2005 13:35:12 -0500
Message-ID: <doc72s$g43$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1390
Lines: 19

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.

--
Joe Seigh

-
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/