rcuref optimization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux