[Gluster-devel] Suggestion to Improve performance

[Mohit Agrawal]

I think we have to update atomic.h/refcount.h also
why ??

There are in fact two types of atomic built-ins provided by gcc:

 (1) The __sync_*() family of functions, which have been in gcc since
     a long time (probably gcc 4.1). They are available in variants
     operating on 1 byte, 2 bytes, 4 bytes and 8 bytes
     integers. Certain architectures implement certain variants,
     certain do not implement any, certain architectures implement all
     of them.

     They are now considered "legacy" by the gcc developers but are
     nonetheless still being used by a significant number of userspace
     libraries and applications.

     https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html

 (2) The __atomic_*() family of functions, which have been introduced
     in gcc 4.7. They have been introduced in order to support C++11
     atomic operations. They are available on all architectures,
     either built-in, or in the libatomic library part of the gcc
     runtime (in which case the application needs to be linked with
     -latomic).

Since (2) are available on all architectures starting gcc 4.7, we do
not need to add any new option for them: packages using them should
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 and link with libatomic.

For more please refer this
http://lists.busybox.net/pipermail/buildroot/2016-January/150499.html

Thanks
Mohit Agrawal

On Wed, Sep 27, 2017 at 2:29 PM, Niels de Vos <ndevos at redhat.com> wrote:

> On Wed, Sep 27, 2017 at 01:47:00PM +0530, Mohit Agrawal wrote:
> > Niels,
> >
> >    Thanks for your reply, I think these built-in function provides by gcc
> > and it should support most of the architecture.
> >    In your view what could be the archietecure that does not support
> these
> > builtin function ??
>
> Yes, these functions and built-in with gcc and probably clang. I think
> i386 does not support them, and maybe some ARM versions do not do so
> either. Some distributions build packages for many different
> architectures, so we need to make sure they can keep on doing that.
> Other distributions do not use gcc, and may not have support for these
> (or the same) atomic operations.
>
> It is not really a problem, as the atomic.h and refcount.h headers have
> fallback implementations (using locks, similar to the current
> situation).
>
> Cheers,
> Niels
>
>
> >
> >
> > Regards
> > Mohit Agrawal
> >
> > On Wed, Sep 27, 2017 at 1:20 PM, Niels de Vos <ndevos at redhat.com> wrote:
> >
> > > On Wed, Sep 27, 2017 at 12:55:37PM +0530, Mohit Agrawal wrote:
> > > > Hi,
> > > >
> > > >    I was checking code of internal data structures (dict,fd,rpc_clnt
> > > etc.)
> > > > those we use in glusterfs to store data.
> > > >    Usually we use common pattern to take reference of data structure
> in
> > > > xlator level, in ref function we do take lock(mutex_lock)
> > > >    and update(increase) reference counter and in unref function we do
> > > take
> > > > lock and decrease reference counter and
> > > >    check if ref counter is become 0 after decrease then destroy
> object.
> > > >
> > > >    I think to update reference counter we don't need to take a lock,
> we
> > > can
> > > > use atomic in-built function those
> > > >    can improve performance
> > >
> > > The below is not portable for all architectures. However we have
> > > refcount.h in libglusterfs/src/ which hides the portability things. One
> > > of the big advantages to use this, is that the code for reference
> > > counting is the same everywhere. Some structures have been updated with
> > > GF_REF_* macros, more can surely be done.
> > >
> > > For other more basic counters that do not function as reference
> counter,
> > > the libglusterfs/src/atomic.h macros can be used. The number of lock
> > > instructions on modern architectures can be reduced considerably this
> > > way. It will likely come with a performance increase, but the usage of
> a
> > > standard API makes the code simpler to understand and that is my main
> > > interest :)
> > >
> > > Obviously I'm all for replacing the lock+count+unlock sequences for
> many
> > > structures!
> > >
> > > Thanks,
> > > Niels
> > >
> > >
> > > >
> > > >    For ex: Below is a example for specific to dict_ref/unref
> > > >    To increase refCount we can use below built-in function
> > > >    dict_ref
> > > >    {
> > > >        __atomic_add_fetch (&this->refcount, 1, __ATOMIC_SEQ_CST);
> > > >
> > > >    }
> > > >
> > > >    dict_unref
> > > >    {
> > > >       __atomic_sub_fetch (&this->refcount, 1, __ATOMIC_SEQ_CST);
> > > >       __atomic_load (&this->refcount, &ref, __ATOMIC_SEQ_CST);
> > > >    }
> > > >
> > > >    In the same way we can use for all other shared data-structure
> also in
> > > > case of take/release reference.
> > > >
> > > >    I have not tested yet how much performance improvement we can gain
> > > but i
> > > > think there should be some improvement.
> > > >   Please share your input on this, appreciate your input.
> > > >
> > > > Regards
> > > > Mohit Agrawal
> > >
> > > > _______________________________________________
> > > > Gluster-devel mailing list
> > > > Gluster-devel at gluster.org
> > > > http://lists.gluster.org/mailman/listinfo/gluster-devel
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170927/f76dbaea/attachment.html>