[Gluster-devel] Suggestion to Improve performance

[Niels de Vos]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170927/4835418e/attachment.sig>