Comments on: Eyecandy mutexes! http://mituzas.lt/2009/02/15/eyecandy-mutexes/ Fri, 30 Jul 2010 21:52:54 +0000 hourly 1 http://wordpress.org/?v=3.1-alpha By: Mark Callaghan http://mituzas.lt/2009/02/15/eyecandy-mutexes/comment-page-1/#comment-188875 Mark Callaghan Mon, 16 Feb 2009 13:33:50 +0000 http://dammit.lt/?p=367#comment-188875 We avoid blobs as much as possibe. I think that Innodb has special code paths for large allocations which blobs might use. 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://mituzas.lt/2009/02/15/eyecandy-mutexes/comment-page-1/#comment-188874 Domas Mituzas Mon, 16 Feb 2009 10:11:58 +0000 http://dammit.lt/?p=367#comment-188874 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. :) 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://mituzas.lt/2009/02/15/eyecandy-mutexes/comment-page-1/#comment-188870 Mark Callaghan Sun, 15 Feb 2009 15:20:21 +0000 http://dammit.lt/?p=367#comment-188870 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 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

]]>