summaryrefslogtreecommitdiffstats
path: root/libglusterfs/src/mem-pool.c
Commit message (Collapse)AuthorAgeFilesLines
* core: avoid NULL pointer dereferenceDmitry Antipov2019-12-051-4/+13
| | | | | | | | | Since low-level __gf_xxx allocation function may be called before ctx is initialized, add extra check for NULL where appropriate. Fixes: bz#1776784 Change-Id: I3127fa4b93f8e3e5846106aadcfed1baa27ac43f Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
* core: fix memory allocation issuesXavi Hernandez2019-06-261-26/+31
| | | | | | | | | | | | | | | | | | | | | | Two problems have been identified that caused that gluster's memory usage were twice higher than required. 1. An off by 1 error caused that all objects allocated from the memory pools were taken from a pool bigger than required. Since each pool corresponds to a size equal to a power of two, this was wasting half of the available memory. 2. The header information used for accounting on each memory object was not taken into consideration when searching for a suitable memory pool. It was added later when each individual block was allocated. This made this space "invisible" to memory accounting. Credits: Thanks to Nithya Balachandran for identifying this problem and testing this patch. Fixes: bz#1722802 Change-Id: I90e27ad795fe51ca11c13080f62207451f6c138c Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* multiple files: another attempt to remove includesYaniv Kaul2019-06-141-2/+2
| | | | | | | | | | | | | | | | | | There are many include statements that are not needed. A previous more ambitious attempt failed because of *BSD plafrom (see https://review.gluster.org/#/c/glusterfs/+/21929/ ) Now trying a more conservative reduction. It does not solve all circular deps that we have, but it does reduce some of them. There is just too much to handle reasonably (dht-common.h includes dht-lock.h which includes dht-common.h ...), but it does reduce the overall number of lines of include we need to look at in the future to understand and fix the mess later one. Change-Id: I550cd001bdefb8be0fe67632f783c0ef6bee3f9f updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* libglusterfs: Fix compilation when --disable-mempool is usedPranith Kumar K2019-05-071-0/+5
| | | | | | updates bz#1193929 Change-Id: I245c065b209bcce5db939b6a0a934ba6fd393b47 Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>
* mem-pool.{c|h}: minor changesYaniv Kaul2019-05-061-25/+12
| | | | | | | | | | | 1. Removed some code that was not needed. It did not really do anything. 2. CALLOC -> MALLOC in one place. Compile-tested only! updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com> Change-Id: I4419161e1bb636158e32b5d33044b06f1eef2449
* core: avoid dynamic TLS allocation when possibleXavi Hernandez2019-04-241-67/+31
| | | | | | | | | | | | | | | | | | | Some interdependencies between logging and memory management functions make it impossible to use the logging framework before initializing memory subsystem because they both depend on Thread Local Storage allocated through pthread_key_create() during initialization. This causes a crash when we try to log something very early in the initialization phase. To prevent this, several dynamically allocated TLS structures have been replaced by static TLS reserved at compile time using '__thread' keyword. This also reduces the number of error sources, making initialization simpler. Updates: bz#1193929 Change-Id: I8ea2e072411e30790d50084b6b7e909c7bb01d50 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* core: fix hang issue in __gf_freeSusant Palai2019-04-221-1/+0
| | | | | | | | | | | | | | | Currently GF_ASSERT is done under mem_accounting lock at some places. On a GF_ASSERT failure, gf_msg_callingfn is called which calls gf_malloc internally and it takes the same mem_accounting lock leading to deadlock. This is a temporary fix to avoid any hang issue in master. https://review.gluster.org/#/c/glusterfs/+/22589/ is being worked on in the mean while so that GF_ASSERT can be used under mem_accounting lock. Change-Id: I6d67f23979e7edd2695bdc6aab2997dae4a4060a updates: bz#1700865 Signed-off-by: Susant Palai <spalai@redhat.com>
* core: handle memory accounting correctlyXavi Hernandez2019-04-221-106/+87
| | | | | | | | | | | | | | | | | | | | When a translator stops, memory accounting for that translator is not destroyed (because there could remain memory allocated that references it), but mutexes that coordinate updates of memory accounting were destroyed. This caused incorrect memory accounting and even crashes in debug mode. This patch also fixes some other things: * Reduce the number of atomic operations needed to manage memory accounting. * Correctly account memory when realloc() is used. * Merge two critical sections into one. * Cleaned the code a bit. Change-Id: Id5eaee7338729b9bc52c931815ca3ff1e5a7dcc8 Updates: bz#1659334 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* mem-pool: remove dead code.Yaniv Kaul2019-03-261-70/+0
| | | | | | Change-Id: I3bbda719027b45e1289db2e6a718627141bcbdc8 updates: bz#1193929 Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
* Revert "iobuf: Get rid of pre allocated iobuf_pool and use per thread mem pool"Amar Tumballi2019-01-081-1/+1
| | | | | | | | | This reverts commit b87c397091bac6a4a6dec4e45a7671fad4a11770. There seems to be some performance regression with the patch and hence recommended to have it reverted. Updates: #325 Change-Id: Id85d6203173a44fad6cf51d39b3e96f37afcec09
* iobuf: Get rid of pre allocated iobuf_pool and use per thread mem poolPoornima G2018-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation of iobuf_pool has two problems: - prealloc of 12.5MB memory, this limits the scale factor of the gluster processes due to RAM requirements - lock contention, as the current implementation has one global iobuf_pool lock. Credits for debugging and addressing the same goes to Krutika Dhananjay <kdhananj@redhat.com>. Issue: #410 Hence changing the iobuf implementation to use per thread mem pool. This may theoritically appear to cause perf dip as there is no preallocation. But per thread mem pool will not have significant perf impact as the last allocated memory is kept alive for subsequent allocs, for some time. The worst case would be if iobufs requested are of random sizes each time. The best case is, if we get iobuf request of the same size. From the perf tests, this patch did not seem to cause any perf decrease. Note that, with this patch, the rdma performance is going to degrade drastically. In one of the previous patchsets we had fixes to not degrade rdma perf, but rdma is not supported and also not tested [1]. Hence the decision was to not have code in rdma that is not tested and not supported. [1] https://lists.gluster.org/pipermail/gluster-users.old/2018-July/034400.html Updates: #325 Change-Id: Ic2ef3bd498f9250dea25f25ba0c01fde19584b27 Signed-off-by: Poornima G <pgurusid@redhat.com>
* mem-pool: Add api to mem_get based on requested sizePoornima G2018-12-171-20/+102
| | | | | | | | | | | | | | | Currently mem-pool implementation provides api to get from the mem pool based on the struct type. This is to retain api compatibility with the old implementation of mem pool. Internally in the mem pool structure there is a mapping from struct to size based pools. In this patch, we are adding new APIs to fetch memory from mem pool, given a size. Change-Id: Ib220ee45ebd134a7be8f6482db5a592dbb7b9211 Updates: #325 Signed-off-by: Poornima G <pgurusid@redhat.com>
* libglusterfs: Move devel headers under glusterfs directoryShyamsundarR2018-12-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | libglusterfs devel package headers are referenced in code using include semantics for a program, this while it works can be better especially when dealing with out of tree xlator builds or in general out of tree devel package usage. Towards this, the following changes are done, - moved all devel headers under a glusterfs directory - Included these headers using system header notation <> in all code outside of libglusterfs - Included these headers using own program notation "" within libglusterfs This change although big, is just moving around the headers and making it correct when including these headers from other sources. This helps us correctly include libglusterfs includes without namespace conflicts. Change-Id: Id2a98854e671a7ee5d73be44da5ba1a74252423b Updates: bz#1193929 Signed-off-by: ShyamsundarR <srangana@redhat.com>
* mem-pool: minor fix and clarificationXavi Hernandez2018-11-281-3/+10
| | | | | | | | | | A comment has been added to pool_destructor() function to explain why locks are not needed there. Also, the initialization of 'poison' field has been moved inside a locked region for further safety and clarity. Change-Id: Idbf23bda7f9228d60c644a1bea4b6c2cfc582090 updates: bz#1193929 Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* libglusterfs: fix memory corruption caused by per-thread mem poolsXavi Hernandez2018-11-261-57/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a race in the per-thread memory pool management that could lead to memory corruption. The race appeared when the following sequence of events happened: 1. Thread T1 allocated a memory object O1 from its own private pool P1 2. T1 terminates and P1 is marked to be destroyed 3. The mem-sweeper thread is woken up and scans all private pools 4. It detects that P1 needs to be destroyed and starts releasing the objects from hot and cold lists. 5. Thread T2 releases O1 6. O1 is added to the hot list of P1 The problem happens because steps 4 and 6 are protected by diferent locks, so they can run concurrently. This means that both T1 and T2 are modifying the same list at the same time, potentially causing corruption. This patch fixes the problem using the following approach: 1. When an object is released, it's only returned to the hot list of the corresponding memory pool if it's not marked to be destroyed. Otherwise the memory is released to the system. 2. Object release and mem-sweeper thread synchronize access to the deletion mark of the memory pool to prevent simultaneous access to the list. Some other minor adjustments are made to reduce the lengths of the locked regions. Fixes: bz#1651165 Change-Id: I63be3893f92096e57f54a6150e0461340084ddde Signed-off-by: Xavi Hernandez <xhernandez@redhat.com>
* coverity: ignore tainted access reported in gf_freeShyamsundarR2018-11-081-1/+7
| | | | | | | | | | | | | Earlier commit had the annotation incorrect, and also did not wrap the sanitization in a separate function. (see commit 39a1db1) The issues are corrected in this patch, and also a coverity stand alone run has been tested to ensure the annotations are respected by coverity. Change-Id: I4a93b6981e2ff4bba9a29e590b17da248931c8ae Updates: bz#789278 Signed-off-by: ShyamsundarR <srangana@redhat.com>
* mem-pool: change the values to 64bitsAmar Tumballi2018-11-011-0/+1
| | | | | | | | | | | | | total_allocs of certain type of variables can be 4billion in a single day depending on load. So, 32 bits for that is not enough. Also, size_t is good variable size for one allocation, but the sum of allocations, should be 64bits to make sure we don't overflow the variable. Updates: bz#1639599 Change-Id: If3b19687f94425e913a0201ae5d73661eda51f06 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* coverity: ignore tainted access reported in gf_freeShyamsundarR2018-10-161-0/+10
| | | | | | | | | | | | | | | | | | Coverity reports tainted pointer access in _gf_free if the pointer passed in was used by any IO related function by the caller. The taint within gf_free is a false positive, as the tainted region is from the passed in pointer till its allocated lenght, and not for contents before the pointer (i.e the GF_MEM_HEADER_SIZE bytes before the passed in pointer), as that is exclusively handled by the gf_alloc family of functions. CID: 1228602, 1292646, 1292647, 1292648, 1292649, 1383192, 1383195, 1389691 Should additionally fix, CID: 1292650, 1292651, 1357874, 1382373, 1382404, 1382407 Change-Id: I48c5a4028e7b0224c432bbc30f8c29408c2a466b Updates: bz#789278 Signed-off-by: ShyamsundarR <srangana@redhat.com>
* Land part 2 of clang-format changesGluster Ant2018-09-121-678/+676
| | | | | Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4 Signed-off-by: Nigel Babu <nigelb@redhat.com>
* coverity: libglusterfs issuesAmar Tumballi2018-08-191-1/+2
| | | | | | | | | CID: 1391415, 1274122, 1274201, 1382408, 1382437, 1389436 1288798, 1288106, 1288110 updates: bz#789278 Change-Id: I48c7a50f22f5f4580310040c66463d9f7dd26204 Signed-off-by: Amar Tumballi <amarts@redhat.com>
* core/memacct: save allocs in mem_acct_rec listN Balachandran2017-12-071-1/+33
| | | | | | | | | | | | | | | With configure --enable-debug, add all object allocations to a list in the corresponding mem_acct_rec. This allows us to see all objects of a particular type and allows for additional debugging in case of memory leaks. This is not compiled in by default and must be explicitly enabled. It is intended to be used by developers. Change-Id: I7cf2dbeadecf994423d7e7591e85f18d2575cce8 BUG: 1522662 Signed-off-by: N Balachandran <nbalacha@redhat.com>
* core: Verify pool pointer before destroying itAkarsha Rai2017-09-291-0/+3
| | | | | | | | | | Problem: Current code is not checking whether the pool pointer is null or not. Solution: Updated the code to verify pool pointer. Bug: 1496675 Change-Id: Ie1f2de4e4204fde15d2b1e3a966ea4c9e7b41534 Signed-off-by: Akarsha Rai <akrai@redhat.com>
* mempool: fix code when GF_DISABLE_MEMPOOL is definedNiels de Vos2017-09-021-3/+5
| | | | | | | | | | | | | | | | | | | | Problem: Run-time crash is observed when attempting to memset() a zero length buffer. Solution: When GF_DISABLE_MEMPOOL is set, mem_get() gets translated to a GF_MALLOC(). The size of the allocation does not need to relate to the available (but uninitialized) global memory pools. It is fine to allocate the exact amount of memory that was configured when the mem-pool was created. Change-Id: Iea0bff974bb771623a34d7a940e10cb0db0f90e1 BUG: 1481199 Reported-by: Milind Changire <mchangir@redhat.com> Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: https://review.gluster.org/18034 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* gfapi: adds a glfs_mem_header for exported memoryKinglong Mee2017-09-011-33/+0
| | | | | | | | | | | | | | | | | | glfs_free releases different types of data depends on memory type. Drop the depends of memory type of memory accounting, new macro GLFS_CALLOC/GLFS_MALLOC/GLFS_REALLOC/GLFS_FREE are added to support assign release function dynamically, it adds a separate memory header named glfs_mem_header for gfapi. Updates: #312 Change-Id: Ie608e5227cbaa05d3f4681a515e83a50d5b17c3f Signed-off-by: Kinglong Mee <mijinlong@open-fs.com> Reviewed-on: https://review.gluster.org/18092 Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Niels de Vos <ndevos@redhat.com> Tested-by: Niels de Vos <ndevos@redhat.com> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us> CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
* mem-pool: count allocations done per user-poolNiels de Vos2017-08-291-0/+5
| | | | | | | | | | | | | | | Count the active allocations per 'struct mem_pool'. These are the objects that the calling component allocated and free'd in the memory pool for this specific type. Having this count in the statedump will make it easy to find memory leaks. Updates: #307 Change-Id: I797fabab86f104e49338c00e449a7d0b0d270004 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: https://review.gluster.org/18074 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* mem-pool: track glusterfs_ctx_t in struct mem_poolNiels de Vos2017-08-291-1/+17
| | | | | | | | | | | | | | | | | | | | In order to generate statedumps per glusterfs_ctx_t, it is needed to place all the memory pools in a structure that the context can reach. The 'struct mem_pool' has been extended with a 'list_head owner' that is linked with the glusterfs_ctx_t->mempool_list. All callers of mem_pool_new() have been updated to pass the current glusterfs_ctx_t along. This context is needed to add the new memory pool to the list and for grabbing the ctx->lock while updating the glusterfs_ctx_t->mempool_list. Updates: #307 Change-Id: Ia9384424d8d1630ef3efc9d5d523bf739c356c6e Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: https://review.gluster.org/18075 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* mem-pool: add tracking of mem_pool that requested the allocationNiels de Vos2017-08-281-28/+32
| | | | | | | | | | | | | | | | | | | | | | | | This renames the current 'struct mem_pool' to 'struct mem_pool_shared'. The mem_pool_shared is globally allocated and not specific for particular objects. A new 'struct mem_pool' gets allocated when mem_pool_new() is called. It points to the mem_pool_shared that handles the actual allocation requests. The 'struct mem_pool' is only used for accounting of the objects that the caller requested and free'd. All of these changes will be used to collect all the memory pools a glusterfs_ctx_t is consuming, so that statedumps can be collected per context. Updates: #307 Change-Id: I6355d3f0251c928e0bbfc71be3431307c6f3a3da Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: https://review.gluster.org/18073 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Amar Tumballi <amarts@redhat.com> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* mem-pool: track and verify initialization stateNiels de Vos2017-07-281-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | | It is possible that pthread_getspecific() returns a non-NULL value in case the pthread_key_t is not initialized. The behaviour for pthread_getspecific() is not defined in this case. This can happen when applications use mem-pools from libglusterfs.so, but did not call mem_pools_init_early(). By tracking the status of the mem-pools initialization, it is now possible to prevent calling pthread_getspecific() in case the pthread_key_t is not initialized. In future, we might want to exend this more to faciliate debugging. Reported-by: Kotresh HR <khiremat@redhat.com> Tested-by: Jiffin Tony Thottan <jthottan@redhat.com> Change-Id: I6255419fe05792dc78b1eaff55bc008fc5ff3933 Fixes: 1e8e62640 ("mem-pool: initialize pthread_key_t pool_key in mem_pool_init_early()") BUG: 1475255 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: https://review.gluster.org/17899 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: jiffin tony Thottan <jthottan@redhat.com> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* mem-pool: free objects from pools on mem_pools_fini()Niels de Vos2017-07-201-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using a minimal gfapi application that only initializes a small graph (sink, shard and meta xlators) the following memory leaks are reported by Valgrind: HEAP SUMMARY: in use at exit: 322,976 bytes in 75 blocks total heap usage: 684 allocs, 609 frees, 2,092,116 bytes allocated With this change, the mem-pools are cleaned up on calling of mem_pools_fini() and the objects in the pool are free'd. HEAP SUMMARY: in use at exit: 315,265 bytes in 58 blocks total heap usage: 684 allocs, 626 frees, 2,092,079 bytes allocated This information was gathered with `./run-xlator.sh features/shard` that comes with `gfapi-load-volfile` from gluster-debug-tools. While working on the free'ing of the per_thread_pool_list_t structures, it became apparent that GF_CALLOC() in mem_get_pool_list() gets redirected to a standard calloc() without prepending the Gluster specific memory header. This is because mem_pools_init() gets called before THIS->ctx is valid, so it is not possible to check if memory accounting is enabled or not. Because of this, the GF_CALLOC() call in mem_get_pool_list() has been replaced by CALLOC() to prevent potential mismatches between the allocation/free'ing of per_thread_pool_list_t structures. Change-Id: Id6f558816f399b0c613d74df36deac2300b6dd98 BUG: 1470170 URL: https://github.com/gluster/gluster-debug-tools Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: https://review.gluster.org/17768 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us> Reviewed-by: soumya k <skoduri@redhat.com>
* mem-pool: initialize pthread_key_t pool_key in mem_pool_init_early()Niels de Vos2017-07-191-14/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is not possible to call pthread_key_delete for the pool_key that is intialized in the constructor for the memory pools. This makes it difficult to do a full cleanup of all the resources in mem_pools_fini(). For this, the initialization of pool_key should be moved to mem_pool_init(). However, the glusterfsd binary has a rather complex initialization procedure. The memory pools need to get initialized partially to get mem_get() functionality working. But, the pool_sweeper thread can get killed in case it is started before glusterfsd deamonizes. In order to solve this, mem_pools_init() is split into two pieces: 1. mem_pools_init_early() for initializing the basic structures 2. mem_pools_init_late() to start the pool_sweeper thread With the split of mem_pools_init(), and placing the pthread_key_create() in mem_pools_init_early(), it is now possible to correctly cleanup the pool_key with pthread_key_delete() in mem_pools_fini(). It seems that there was no memory pool initialization in the CLI. This has been added as well now. Without it, the CLI will not be able to call mem_get() successfully which results in a hang of the process. Change-Id: I1de0153dfe600fd79eac7468cc070e4bd35e71dd BUG: 1470170 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: https://review.gluster.org/17779 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* libglusterfs: Name threads on creationRaghavendra Talur2017-07-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set names to threads on creation for easier debugging. Output of top -H -p <PID-OF-GLUSTERFSD> Before: 19773 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19774 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19775 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19776 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19777 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19778 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19779 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19780 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19781 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19782 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19783 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19784 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19785 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.01 glusterfsd 19786 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.01 glusterfsd 19787 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.01 glusterfsd 19789 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19790 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 25178 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 5398 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 7881 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd After: 19773 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19774 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glustertimer 19775 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterfsd 19776 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glustermemsweep 19777 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glustersproc0 19778 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glustersproc1 19779 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterepoll0 19780 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusteridxwrker 19781 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusteriotwr0 19782 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterbrssign 19783 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterbrswrker 19784 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterclogecon 19785 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.01 glusterclogd0 19786 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.01 glusterclogd1 19787 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.01 glusterclogd2 19789 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterposixjan 19790 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterposixfsy 25178 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterepoll1 5398 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterepoll2 7881 root 20 0 1301.3m 12.6m 8.4m S 0.0 0.1 0:00.00 glusterposixhc Change-Id: Id5f333755c1ba168a2ffaa4fce6e71c375e10703 BUG: 1254002 Updates: #271 Signed-off-by: Raghavendra Talur <rtalur@redhat.com> Reviewed-on: https://review.gluster.org/11926 Reviewed-by: Prashanth Pai <ppai@redhat.com> Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Niels de Vos <ndevos@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
* gfapi+libglusterfs: fix mem_pools_fini without mem_pools_init caseJeff Darcy2017-07-091-2/+16
| | | | | | | | | | | | | | The change consists of two parts: make sure it doesn't happen (in glfs.c), and make it harmless if it does (in mem-pool.c). Change-Id: Icb7dda7a45dd3d1ade2ee3991bb6a22c8ec88424 BUG: 1468863 Signed-off-by: Jeff Darcy <jdarcy@fb.com> Reviewed-on: https://review.gluster.org/17728 Tested-by: Jeff Darcy <jeff@pl.atyp.us> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* libglusterfs: add mem_pools_finiJeff Darcy2017-07-011-5/+28
| | | | | | | | | | | | | | | This also makes mem_pools_init and mem_pools_fini re-callable, so GFAPI can go through infinite init/fini cycles if they want to. Not saying that's a good idea, but at least it's safe. Change-Id: I617913410bcff54568b802cb653f48bdd533bd65 Signed-off-by: Jeff Darcy <jdarcy@fb.com> Reviewed-on: https://review.gluster.org/17662 Smoke: Gluster Build System <jenkins@build.gluster.org> Tested-by: Jeff Darcy <jeff@pl.atyp.us> Reviewed-by: Niels de Vos <ndevos@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* libglusterfs: fix disable-mempoolJeff Darcy2017-06-281-3/+3
| | | | | | | | | | | | Change-Id: I55f707ae1e7c3ad7fc0545f7aa657584cead58f9 BUG: 1465214 Signed-off-by: Jeff Darcy <jdarcy@fb.com> Reviewed-on: https://review.gluster.org/17636 Smoke: Gluster Build System <jenkins@build.gluster.org> Tested-by: Jeff Darcy <jeff@pl.atyp.us> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Ji-Hyeon Gim Reviewed-by: Amar Tumballi <amarts@redhat.com>
* libglusterfs: build failed with GF_DISABLE_MEMPOOLJi-Hyeon Gim2017-06-271-1/+1
| | | | | | | | | | | | | | | | When we build GlusterFS with GF_DISBLE_MEMPOOL, it is failed due to macro condition in mem-pool.c:mem_get(). Change-Id: I03fe804f93d761ea3bfdc3b20f0253a03350a68f BUG: 1465214 Signed-off-by: Ji-Hyeon Gim <potatogim@potatogim.net> Reviewed-on: https://review.gluster.org/17633 Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Vijay Bellur <vbellur@redhat.com> Reviewed-by: jiffin tony Thottan <jthottan@redhat.com> Tested-by: Ji-Hyeon Gim CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Niels de Vos <ndevos@redhat.com>
* mem-pool: use gf_atomic_t for atomic countersNiels de Vos2017-04-101-4/+9
| | | | | | | | | | | | | | | | 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@redhat.com> Reviewed-on: https://review.gluster.org/17012 NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com> Reviewed-by: Amar Tumballi <amarts@redhat.com>
* libglusterfs: provide standardized atomic operationsNiels de Vos2017-04-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@redhat.com> Reviewed-on: https://review.gluster.org/16963 Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Xavier Hernandez <xhernandez@datalab.es> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Amar Tumballi <amarts@redhat.com> Reviewed-by: Jeff Darcy <jeff@pl.atyp.us>
* Free arg_save when malloc failMichael Scherer2017-02-281-0/+1
| | | | | | | | | | | | | | Warning found by coverity. Change-Id: Ie755659c33a43a440dadfeb1499a2f6c08e3f625 BUG: 789278 Signed-off-by: Michael Scherer <misc@redhat.com> Reviewed-on: https://review.gluster.org/16788 Tested-by: Michael Scherer <misc@fedoraproject.org> Smoke: Gluster Build System <jenkins@build.gluster.org> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com>
* libglusterfs: make memory pools more thread-friendlyJeff Darcy2017-02-021-221/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Early multiplexing tests revealed *massive* contention on certain pools' global locks - especially for dictionaries and secondarily for call stubs. For the thread counts that multiplexing can create, a more lock-free solution is clearly needed. Also, the current mem-pool implementation does a poor job releasing memory back to the system, artificially inflating memory usage to match whatever the worst case was since the process started. This is bad in general, but especially so for multiplexing where there are more pools and a major point of the whole exercise is to reduce memory consumption. The basic ideas for the new design are these There is one pool, globally, for each power-of-two size range. Every attempt to create a new pool within this range will instead add a reference to the existing pool. Instead of adding pools for each translator within each multiplexed brick (potentially infinite and quite possibly thousands), we allocate one set of size-based pools per *thread* (hundreds at worst). Each per-thread pool is divided into hot and cold lists. Every allocation first attempts to use the hot list, then the cold list. When objects are freed, they always go on the hot list. There is one global "pool sweeper" thread, which periodically reclaims everything in each pool's cold list and then "demotes" the current hot list to be the new cold list. For normal allocation activity, only a per-thread lock need be taken, and even that only to guard against very rare contention from the pool sweeper. When threads start and stop, a global lock must be taken to add them to the pool sweeper's list. Lock contention is therefore extremely low, and the hot/cold lists also provide good locality. A more complete explanation (of a similar earlier design) can be found here: http://www.gluster.org/pipermail/gluster-devel/2016-October/051160.html Change-Id: I5bc8a1ba57cfb553998f979a498886e0d006e665 BUG: 1385758 Signed-off-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-on: https://review.gluster.org/15645 Reviewed-by: Xavier Hernandez <xhernandez@datalab.es> Smoke: Gluster Build System <jenkins@build.gluster.org> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com>
* core: Disable the memory pooler in Gluster via a build flagShreyas Siravara2017-01-041-2/+16
| | | | | | | | | | | | | | | | | Summary: Passing --disable-mempool to configure will disable the mempool. Change-Id: I60d5f70d54de507fe9f4695d7589f7ae1ba4bb0f BUG: 1405165 Signed-off-by: Shreyas Siravara <sshreyas@fb.com> Reviewed-on: http://review.gluster.org/16148 Smoke: Gluster Build System <jenkins@build.gluster.org> Tested-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-by: Niels de Vos <ndevos@redhat.com> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Anoop C S <anoopcs@redhat.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org>
* libglusterfs:Now mempool is added to ctx pool list under a lockRajesh Joseph2016-11-221-1/+5
| | | | | | | | | | | | | | | | | | | mempool is added to ctx pool list without any lock. This can cause undefined behaviour in case of multithreaded environment. Fix: modify the list only under ctx->lock Change-Id: I7bdbb3db48a899bb0e41427e149b13c0facaedba Signed-off-by: Rajesh Joseph <rjoseph@redhat.com> BUG: 1394719 Reviewed-on: http://review.gluster.org/15842 NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Raghavendra Talur <rtalur@redhat.com> Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com> Reviewed-by: Poornima G <pgurusid@redhat.com> Reviewed-by: Niels de Vos <ndevos@redhat.com>
* libglusterfs/mem-pool: fix unused variable warnings/errorsKaleb S. KEITHLEY2016-09-161-1/+0
| | | | | | | | | | | | | | | | | | http://review.gluster.org/14085 fixes a "pragma leak" where the generated rpc/xdr headers have a pair of pragmas that disable these warnings. With the warnings disabled, many unused variables have crept into the code base. And 14085 won't pass its own smoke test until all these warnings are fixed. BUG: 1369124 Change-Id: I8885e4d4aa44307c240413ba6f35ecd59ab45444 Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com> Reviewed-on: http://review.gluster.org/15516 Smoke: Gluster Build System <jenkins@build.gluster.org> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org>
* libglusterfs: add gf_get_mem_type()Niels de Vos2016-08-151-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | gfapi needs to provide a function towards applications to free memory that it allocated. Depending on how the application is compiled/linked, it could use a different memory allocator than Gluster itself. Therefore it is not safe for gfapi to request applications to free memory with 'standard' free(). Examples for this are Gluster allocated structures with GF_CALLOC() when memory accounting is enabled (the default). Some gfapi functions use malloc() to allocate memory as a workaround, but the free() from the jemalloc implementation should not be combined with the malloc() from glibc. Change-Id: I626cd1a60abf8965f9263290f4045d1f69fc2093 BUG: 1344714 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: http://review.gluster.org/15108 Smoke: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: soumya k <skoduri@redhat.com> Reviewed-by: jiffin tony Thottan <jthottan@redhat.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Shyamsundar Ranganathan <srangana@redhat.com>
* libglusterfs: fix glusterd statedump crashAtin Mukherjee2016-08-041-0/+4
| | | | | | | | | | | | | | | | | | commit 3c04a91 removed setting typeStr to NULL if num_allocs is set to 0, this has caused this regression. Code has been put back like earlier and to avoid statedump printing all the NULL values check is modified to see skip the records if num_allocs is 0 instead of total_allocs Change-Id: Ib8bcc2fba908e88cf52b641c3f6bcba74f5e667c BUG: 1359190 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> Reviewed-on: http://review.gluster.org/14987 NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: N Balachandran <nbalacha@redhat.com> Reviewed-by: Prashanth Pai <ppai@redhat.com> Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
* statedump: Prevent (null) typestr to be printedPranith Kumar K2016-04-241-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Problem: After the commits: 7e44c783ad731856956929f6614bbe045c26ea3a - lock: use spinlock only on multicore systems a6aecae2cd8171b8538bfe5d2800bdd157380b85 - nfs: fix lock variable type we see a lot of "[global.glusterfs - usage-type (null) memusage]" in statedump because lock status is not all-zeros after init, and the memcmp to check that a datatype is never allocated is invalid. Fix: Changed if a datatype is allocated or not check based on total_allocs. Also removed setting typestr to NULL on gf_free even when num_allocs is 0. Because even that is leading to 'null' memusage string to be printed in statedump. BUG: 1329870 Change-Id: If2b01a557cbdc787625db32e276e06cee3ac46ee Signed-off-by: Pranith Kumar K <pkarampu@redhat.com> Reviewed-on: http://review.gluster.org/14054 Smoke: Gluster Build System <jenkins@build.gluster.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Niels de Vos <ndevos@redhat.com>
* libglusterfs: coverity fixSakshi2016-04-141-0/+1
| | | | | | | | | | | | | | | | | | | fix missing varargs cleanup CID 1124856: string overflow CID 1124656: NULL return CID 1124374: constant expression Change-Id: Iead530c599bdfef05a40c68b892215f4e4f02247 BUG: 789278 Signed-off-by: Sakshi Bansal <sabansal@redhat.com> Reviewed-on: http://review.gluster.org/9630 Smoke: Gluster Build System <jenkins@build.gluster.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
* mem-pool,stack,store,syncop,timer/libglusterfs : Porting to a new logging ↵Mohamed Ashiq2015-06-261-12/+24
| | | | | | | | | | | framework Change-Id: Idd3dcaf7eeea5207b3a5210676ce3df64153197f BUG: 1194640 Signed-off-by: Mohamed Ashiq <ashiq333@gmail.com> Reviewed-on: http://review.gluster.org/10827 Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com> Tested-by: NetBSD Build System <jenkins@build.gluster.org>
* core: use reference counting for mem_acct structuresJeff Darcy2015-05-091-42/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When freeing memory, our memory-accounting code expects to be able to dereference from the (previously) allocated block to its owning translator. However, as we have already found once in option validation and twice in logging, that translator might itself have been freed and the dereference attempt causes on of our daemons to crash with SIGSEGV. This patch attempts to fix that as follows: * We no longer embed a struct mem_acct directly in a struct xlator, but instead allocate it separately. * Allocated memory blocks now contain a pointer to the mem_acct instead of the xlator. * The mem_acct structure contains a reference count, manipulated in both the normal and translator allocate/free code using atomic increments and decrements. * Because it's now a separate structure, we can defer freeing the mem_acct until its reference count reaches zero (either way). * Some unit tests were disabled, because they embedded their own copies of the implementation for what they were supposedly testing. Life's too short to spend time fixing tests that seem designed to impede progress by requiring a certain implementation as well as behavior. Change-Id: Id929b11387927136f78626901729296b6c0d0fd7 BUG: 1211749 Signed-off-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-on: http://review.gluster.org/10417 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com> Reviewed-by: Niels de Vos <ndevos@redhat.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu@redhat.com>
* mem-pool: invalidate memory on GF_FREE to aid debuggingNiels de Vos2015-03-301-53/+83
| | | | | | | | | | | | | | | | | | | | | | | | Debugging where memory gets free'd with help from overwriting the memory before it is free'd with some structures (repeatedly). The struct mem_invalid starts with a magic value (0xdeadc0de), followed by a pointer to the xlator, the mem-type. the size of the GF_?ALLOC() requested area and the baseaddr pointer to what GF_?ALLOC() returned. With these details, and the 'struct mem_header' that is placed when calling GF_?ALLOC(), it is possible to identify overruns and possible use-after-free. A memory dump (core) or running with a debugger is needed to read the surrounding memory of corrupt structures. This additional memory invalidation/poisoning needs to be enabled by passing --enable-debug to ./configure. Change-Id: I9f5f37dc4b5b59142adefc90897d32e89be67b82 Signed-off-by: Niels de Vos <ndevos@redhat.com> Reviewed-on: http://review.gluster.org/10019 Reviewed-by: Venky Shankar <vshankar@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Emmanuel Dreyfus <manu@netbsd.org> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
* testing: Switch to cmocka the successor of cmockery2Niels de Vos2015-03-051-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This uses https://cmocka.org/ as the unit testing framework. With this change, unit testing is made optional as well. We assume there is no cmocka available while building. cmocka will be enabled by default later on. For now, to build with cmocka run: $ ./configure --enable-cmocka This change is based on the work of Andreas (replacing cmockery2 with cmocka) and Kaleb (make cmockery2 an optional build dependency). The only modifications I made, are additional #defines in unittest.h for making sure the unit tests function as expected. Change-Id: Iea4cbcdaf09996b49ffcf3680c76731459cb197e BUG: 1067059 Merged-change: http://review.gluster.org/9762/ Signed-off-by: Andreas Schneider <asn@samba.org> Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com> Signed-off-by: Niels de Vos <ndevos@redhat.com> Change-Id: Ia2e955481c102d5dce17695a9205395a6030e985 Reviewed-on: http://review.gluster.org/9738 Tested-by: Gluster Build System <jenkins@build.gluster.com>
generated by cgit (git 2.34.1) at 2024-05-06 00:08:06 +0000