<div dir="ltr">I think we have to update atomic.h/refcount.h also <div>why ??</div><div><div><br></div><div>There are in fact two types of atomic built-ins provided by gcc:</div><div><br></div><div> (1) The __sync_*() family of functions, which have been in gcc since</div><div> a long time (probably gcc 4.1). They are available in variants</div><div> operating on 1 byte, 2 bytes, 4 bytes and 8 bytes</div><div> integers. Certain architectures implement certain variants,</div><div> certain do not implement any, certain architectures implement all</div><div> of them.</div><div><br></div><div> They are now considered "legacy" by the gcc developers but are</div><div> nonetheless still being used by a significant number of userspace</div><div> libraries and applications.</div><div><br></div><div> <a href="https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html">https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html</a></div><div><br></div><div> (2) The __atomic_*() family of functions, which have been introduced</div><div> in gcc 4.7. They have been introduced in order to support C++11</div><div> atomic operations. They are available on all architectures,</div><div> either built-in, or in the libatomic library part of the gcc</div><div> runtime (in which case the application needs to be linked with</div><div> -latomic).</div><div><br></div><div>Since (2) are available on all architectures starting gcc 4.7, we do</div><div>not need to add any new option for them: packages using them should</div><div>depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 and link with libatomic.</div><div><br></div><div>For more please refer this</div><div><a href="http://lists.busybox.net/pipermail/buildroot/2016-January/150499.html">http://lists.busybox.net/pipermail/buildroot/2016-January/150499.html</a></div></div><div><br></div><div>Thanks</div><div>Mohit Agrawal</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 27, 2017 at 2:29 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 27, 2017 at 01:47:00PM +0530, Mohit Agrawal wrote:<br>
> Niels,<br>
><br>
> Thanks for your reply, I think these built-in function provides by gcc<br>
> and it should support most of the architecture.<br>
> In your view what could be the archietecure that does not support these<br>
> builtin function ??<br>
<br>
</span>Yes, these functions and built-in with gcc and probably clang. I think<br>
i386 does not support them, and maybe some ARM versions do not do so<br>
either. Some distributions build packages for many different<br>
architectures, so we need to make sure they can keep on doing that.<br>
Other distributions do not use gcc, and may not have support for these<br>
(or the same) atomic operations.<br>
<br>
It is not really a problem, as the atomic.h and refcount.h headers have<br>
fallback implementations (using locks, similar to the current<br>
situation).<br>
<br>
Cheers,<br>
Niels<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
><br>
> Regards<br>
> Mohit Agrawal<br>
><br>
> On Wed, Sep 27, 2017 at 1:20 PM, Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
><br>
> > On Wed, Sep 27, 2017 at 12:55:37PM +0530, Mohit Agrawal wrote:<br>
> > > Hi,<br>
> > ><br>
> > > I was checking code of internal data structures (dict,fd,rpc_clnt<br>
> > etc.)<br>
> > > those we use in glusterfs to store data.<br>
> > > Usually we use common pattern to take reference of data structure in<br>
> > > xlator level, in ref function we do take lock(mutex_lock)<br>
> > > and update(increase) reference counter and in unref function we do<br>
> > take<br>
> > > lock and decrease reference counter and<br>
> > > check if ref counter is become 0 after decrease then destroy object.<br>
> > ><br>
> > > I think to update reference counter we don't need to take a lock, we<br>
> > can<br>
> > > use atomic in-built function those<br>
> > > can improve performance<br>
> ><br>
> > The below is not portable for all architectures. However we have<br>
> > refcount.h in libglusterfs/src/ which hides the portability things. One<br>
> > of the big advantages to use this, is that the code for reference<br>
> > counting is the same everywhere. Some structures have been updated with<br>
> > GF_REF_* macros, more can surely be done.<br>
> ><br>
> > For other more basic counters that do not function as reference counter,<br>
> > the libglusterfs/src/atomic.h macros can be used. The number of lock<br>
> > instructions on modern architectures can be reduced considerably this<br>
> > way. It will likely come with a performance increase, but the usage of a<br>
> > standard API makes the code simpler to understand and that is my main<br>
> > interest :)<br>
> ><br>
> > Obviously I'm all for replacing the lock+count+unlock sequences for many<br>
> > structures!<br>
> ><br>
> > Thanks,<br>
> > Niels<br>
> ><br>
> ><br>
> > ><br>
> > > For ex: Below is a example for specific to dict_ref/unref<br>
> > > To increase refCount we can use below built-in function<br>
> > > dict_ref<br>
> > > {<br>
> > > __atomic_add_fetch (&this->refcount, 1, __ATOMIC_SEQ_CST);<br>
> > ><br>
> > > }<br>
> > ><br>
> > > dict_unref<br>
> > > {<br>
> > > __atomic_sub_fetch (&this->refcount, 1, __ATOMIC_SEQ_CST);<br>
> > > __atomic_load (&this->refcount, &ref, __ATOMIC_SEQ_CST);<br>
> > > }<br>
> > ><br>
> > > In the same way we can use for all other shared data-structure also in<br>
> > > case of take/release reference.<br>
> > ><br>
> > > I have not tested yet how much performance improvement we can gain<br>
> > but i<br>
> > > think there should be some improvement.<br>
> > > Please share your input on this, appreciate your input.<br>
> > ><br>
> > > Regards<br>
> > > Mohit Agrawal<br>
> ><br>
> > > ______________________________<wbr>_________________<br>
> > > Gluster-devel mailing list<br>
> > > <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> > > <a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
> ><br>
> ><br>
</div></div></blockquote></div><br></div>