Comments on: Eyecandy mutexes! http://dom.as/2009/02/15/eyecandy-mutexes/ Sat, 17 Dec 2011 20:14:59 +0000 hourly 1 http://wordpress.com/ By: Mark Callaghan http://dom.as/2009/02/15/eyecandy-mutexes/#comment-1470 Mon, 16 Feb 2009 13:33:50 +0000 http://dammit.lt/?p=367#comment-1470 We avoid blobs as much as possibe. I think that Innodb has special code paths for large allocations which blobs might use.

]]> By: Domas Mituzas http://dom.as/2009/02/15/eyecandy-mutexes/#comment-1469 Mon, 16 Feb 2009 10:11:58 +0000 http://dammit.lt/?p=367#comment-1469 damnit, to figure out where the problem was happening I rebuilt 5.1.30 with -fno-inline and now I’m hitting mem_pool mutexes, rather than ut_malloc one. Debugging inlined functions has always been pain :) Maybe I had some specific situation/edge case, where it was being hit, but I reproduced it on both 4.0 and 5.1 (I’m not sure I even have anything else on this Solaris box).

Will try to understand what is happening in code path more.

Yes, I was using dtrace plockstat thing here.

The workload was BLOB reading en-masse. :)

]]> By: Mark Callaghan http://dom.as/2009/02/15/eyecandy-mutexes/#comment-1468 Sun, 15 Feb 2009 15:20:21 +0000 http://dammit.lt/?p=367#comment-1468 Domas,
Looking at the code for 5.0.67 and based on the call stack that you provide, the call chain is mem_heap_create_block -> mem_area_alloc -> ut_malloc -> ut_malloc_low. There are a couple of things to note:
* mem_area_alloc/mem_area_free is protected by a separate mutex that can be hot
* mem_area_alloc only calls ut_malloc when the mem_pool_t runs out of memory
* most of us don’t get to use dtrace. Were you using it?
* I have not had see the ut_malloc mutex get hot. What workload did you use?
* the Google patch changes mem_area_malloc/mem_area_free to call malloc/free directly. Even without tcmalloc, most system libraries are probably better than what is provided by mem_area_alloc/mem_area_free/mem_pool_t for multithreaded usage

]]>