Hi, so, what will mtmalloc do with it? The default malloc() is bad for multithreaded apps and even libumem has its limits. mtmalloc was improved significantly during last years.
Best regards, Milan Bob Friesenhahn píše v st 11. 04. 2012 v 13:06 -0500: > On Wed, 11 Apr 2012, Dan McDonald wrote: > > > > One other thing you may wish to try is use libumem's version of malloc() > > instead. You can run libumem w/o any recompilation by doing stupid > > environment tricks: > > > > LD_PRELOAD=libumem.so > > > > will be enough to make libumem's version of malloc be used instead of > > libc's. > > > > Not sure if it'll help you, but it's a worthy experiment. > > This was a good suggestion and in fact I already switched to using > libumem since my previous email. My application has a specific > configuration option to use libumem. > > I am still seeing considerable time attributed to the memory allocator > and in fact it is reported as the high-runner for mutex blocks even > though there are very few calls to it. For this case, my > application's own locks (starting with gm`) are in the noise: > > Mutex block > > Count nsec Lock Caller > ------------------------------------------------------------------------------- > 44 24826292 libc.so.1`__sbrk_lock libumem.so.1`vmem_sbrk_alloc+0x84 > 62 1071393 0x7a5030 libumem.so.1`vmem_xalloc+0xe8 > 46 1397292 0x7a5030 libumem.so.1`vmem_xalloc+0x675 > 71 898233 0x7a5030 libumem.so.1`vmem_alloc+0x7e > 13 699682 libumem.so.1`vmem0+0x30 libumem.so.1`vmem_alloc+0x7e > 5 953203 libumem.so.1`vmem0+0x30 libumem.so.1`vmem_xalloc+0x6a5 > 10 429394 libc.so.1`_uberdata+0x2900 libc.so.1`_lwp_start > 5 644450 libumem.so.1`vmem0+0x30 libumem.so.1`vmem_contains+0x30 > 4 531624 libumem.so.1`vmem0+0x30 libumem.so.1`vmem_xalloc+0xe8 > 15 109154 0x875340 gm`ConvolveImage._omp_fn.8+0x11e > 17 93406 0x855040 gm`LockSemaphoreInfo+0x3d > 10 154880 libumem.so.1`vmem0+0xc38 libumem.so.1`vmem_alloc+0x7e > 4 354445 libumem.so.1`vmem0+0xc38 libumem.so.1`vmem_xalloc+0x675 > 18 71054 0x875340 gm`ConvolveImage._omp_fn.8+0x97 > 3 395671 libumem.so.1`vmem_nosleep_lock libumem.so.1`vmem_populate+0xb2 > 4 187098 libumem.so.1`vmem0+0xc38 libumem.so.1`vmem_xalloc+0xe8 > 8 92230 libc.so.1`_uberdata+0x2900 > libgomp.so.1.0.0`gomp_thread_start+0x24 > 14 52305 0x855010 gm`LockSemaphoreInfo+0x3d > 13 30087 0x855cd0 gm`LockSemaphoreInfo+0x3d > 1 388634 libumem.so.1`vmem_nosleep_lock libumem.so.1`vmem_populate+0xb2 > 5 65664 0x855d00 gm`LockSemaphoreInfo+0x3d > 2 154188 libumem.so.1`vmem_segfree_lock > libumem.so.1`vmem_getseg_global+0x16 > 1 157818 libumem.so.1`vmem_nosleep_lock libumem.so.1`vmem_populate+0xb2 > 1 54092 libc.so.1`_uberdata+0x40 LM1`ld.so.1`rt_bind_guard+0x42 > 2 16986 libumem.so.1`vmem_segfree_lock > libumem.so.1`vmem_getseg_global+0x16 > 1 11806 0x1f5980a0 > libgomp.so.1.0.0`gomp_team_barrier_wait+0x11 > 1 10651 0x875340 gm`ConvolveImage._omp_fn.8+0x11e > > Bob ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
