Description of problem: There are ATOMIC_INCREMENT() and ATOMIC_DECREMENT() macros available, these use locks for non-atomic architectures. The locking is non-transparent and is applied differently in several use-cases. I'll be cleaning this locking up, and making all architectures behave the same (a lock per variable, or no locks at all).
REVIEW: https://review.gluster.org/16963 (libglusterfs: provide standardized atomic operations) posted (#1) for review on master by Niels de Vos (ndevos)
REVIEW: https://review.gluster.org/16963 (libglusterfs: provide standardized atomic operations) posted (#2) for review on master by Niels de Vos (ndevos)
REVIEW: https://review.gluster.org/16963 (libglusterfs: provide standardized atomic operations) posted (#3) for review on master by Niels de Vos (ndevos)
REVIEW: https://review.gluster.org/16963 (libglusterfs: provide standardized atomic operations) posted (#4) for review on master by Niels de Vos (ndevos)
REVIEW: https://review.gluster.org/16963 (libglusterfs: provide standardized atomic operations) posted (#5) for review on master by Niels de Vos (ndevos)
REVIEW: https://review.gluster.org/16963 (libglusterfs: provide standardized atomic operations) posted (#6) for review on master by Niels de Vos (ndevos)
COMMIT: https://review.gluster.org/16963 committed in master by Jeff Darcy (jeff.us) ------ commit 93e3c9abce1a02ac724afa382751852fa5edf713 Author: Niels de Vos <ndevos> Date: Wed Mar 29 13:44:03 2017 +0200 libglusterfs: provide standardized atomic operations The current macros ATOMIC_INCREMENT() and ATOMIC_DECREMENT() expect a lock as first argument. There are at least two issues with this approach: 1. this lock is unused on architectures that have atomic operations 2. some structures use a single lock for multiple variables By defining a gf_atomic_t type, the unused lock can be removed, saving a few bytes on modern architectures. Because the gf_atomic_t type locates the lock for the variable (in case of older architectures), each variable is protected the same on all architectures. This makes the behaviour across all architectures more equal (per variable locking, by a gf_lock_t or compiler optimization). BUG: 1437037 Change-Id: Ic164892b06ea676e6a9566f8a98b7faf0efe76d6 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: https://review.gluster.org/16963 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Xavier Hernandez <xhernandez> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Amar Tumballi <amarts> Reviewed-by: Jeff Darcy <jeff.us>
REVIEW: https://review.gluster.org/17009 (io-stats: use gf_atomic_t instead of partial atomic variables) posted (#1) for review on master by Niels de Vos (ndevos)
REVIEW: https://review.gluster.org/17009 (io-stats: use gf_atomic_t instead of partial atomic variables) posted (#2) for review on master by Niels de Vos (ndevos)
REVIEW: https://review.gluster.org/17012 (mem-pool: use gf_atomic_t for atomic counters) posted (#1) for review on master by Niels de Vos (ndevos)
COMMIT: https://review.gluster.org/17012 committed in master by Jeff Darcy (jeff.us) ------ commit ec0e1176d476ef5765efe7713ce6a57f2f081722 Author: Niels de Vos <ndevos> Date: Fri Apr 7 13:02:08 2017 +0200 mem-pool: use gf_atomic_t for atomic counters Reduce the usage of __sync_fetch_and_add() builtins in mem-pool. The new gf_atomic_t type can be used instead, so that the architecture and compiler specific builtins are hidden from the mem-pool implementation. BUG: 1437037 Change-Id: Icbeeb187dd2b835b35f32f54f821ceddfc7b2638 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: https://review.gluster.org/17012 NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Smoke: Gluster Build System <jenkins.org> Reviewed-by: Kaleb KEITHLEY <kkeithle> Reviewed-by: Amar Tumballi <amarts>
COMMIT: https://review.gluster.org/17009 committed in master by Jeff Darcy (jeff.us) ------ commit 3594f960a8b5ccf81b6d06c89003f175ddd6a2c8 Author: Niels de Vos <ndevos> Date: Thu Apr 6 15:11:00 2017 +0200 io-stats: use gf_atomic_t instead of partial atomic variables io-stats should not use the legacy __sync_*() builtin functions for doing atomic operations. Instead, it should use the gf_atomic_t type and macros for any of the statistics it calculates. This makes sure that the behaviour is the same on all architectures. Also the __sync_*() builtins are being deprecated with __atomic_*() functions. The "atomic.h" header will be one of the very few places where these builtin functions are used and the feature checking will be needed. While replacing many of the uint64_t types, it seemed that locking around some of the statements is not needed anymore (done automatically with the GF_ATOMIC_*() macros). This resulted in quite some removal and cleanup of those BUMP_*() macros. It seemed appropriate to make these macros normal functions and let the compiler decide on inlining them. This caused some existing functions to be shuffled around. Change-Id: I7c4f3df1832eae51debda2b127b943e14546b605 URL: https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html BUG: 1437037 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: https://review.gluster.org/17009 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Amar Tumballi <amarts> Reviewed-by: Jeff Darcy <jeff.us>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.11.0, please open a new bug report. glusterfs-3.11.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://lists.gluster.org/pipermail/announce/2017-May/000073.html [2] https://www.gluster.org/pipermail/gluster-users/