GNOME Bugzilla – Bug 116805
glib2 scales badly on SMP systems
Last modified: 2011-02-18 16:13:53 UTC
We are using glib in a massively multithreaded application, and some parts of GLib scales poorly when more than a single processor is installed in the system. We first identified the GString mem_chunk, more precisely the lock protecting that mem_chunk to be a bottleneck. The attached patch is a quick&dirty workaround which uses a per-thread memchunk, thus avoids locking. A better solution would be to make GMemChunk reentrant and move locking to lower levels.
Created attachment 18071 [details] [review] make GString use a per-thread GMemChunk for allocation to avoid locking
Please forget the patch, as more serious testing revealed that it does not work when a g_string_new and g_string_free is called from different threads.
Does compiling glib with --disable-mem-pools improve the scalability ?
scalability improves, but performance drops for one processor. and by-the-way this configuration leaks memory (as the GMemPools do not free anything in this case)
Are you maybe confusing DISABLE_MEM_POOLS with G_ALLOC_ONLY ? If you're compiling glib with --disable-mem-pools, g_mem_chunk_alloc()/g_mem_chunk_free() directly map to g_malloc()/g_free(), so stuff should definitively be freed in this case.
I don't confuse those. GHashTable for instance uses G_ALLOC_ONLY GMemPools and never calls g_mem_chunk_free, but assumes that g_mem_chunk_destroy frees all allocated chunks, but with DISABLE_MEM_POOLS defined this does not happen. And another btw why do nearly all the GMemChunk users (GList, GTree etc) have their own free lists? This functionality is implemented by GMemChunks as well. This seems to be a duplication to me.
bug 118439 is related to this
I think we should dup this to 118439, we only need one bug about fixing the memory system *** This bug has been marked as a duplicate of 118439 ***