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
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------
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

Reply via email to