I'm working with your branch Walt. Most of the code that does
allocation of the client state machines is the same.
-sam
On Oct 24, 2006, at 9:10 AM, Walter B. Ligon III wrote:
Should be careful here, since all of the code dealing with
PINT_client_sm's have been rewritten for the new SM code and
Murali's suggestions (for example) may not work so well.
Walt
Murali Vilayannur wrote:
Hey Sam,
I ran pvfs2-client-core in valgrind, and then ran Bonnie++ a few
times (10) on the mounted pvfs volume, and noticed the following
when I stopped the client process:
==20132== malloc/free: 1,298,824 allocs, 1,297,888 frees,
3,462,517,583 bytes allocated.
Allocating and freeing 3.5GB seemed extreme, so I went
exploring. It turns out that every time we allocate a
PINT_client_sm, we're allocating about 35KB:
(gdb) p sizeof(struct PINT_client_sm)
$4 = 37764
Oh boy.. that is definitely large..
static array of 8 PINT_client_lookup_sm_ctx, which itself has a
static array 40 PINT_client_lookup_sm_segment, which are each
about 112 bytes. Anyway, it ends up accumulating.
So I'm convinced at this point that this is beyond the noise
range, plus its just cruft that we don't need. I'd like to swap
out those static arrays for dynamic allocation when we get to the
start of the lookup state machine. Any thoughts or suggestions?
I agree. It definitely does not look like noise region anymore.
How about we keep a pool of PINT_client_sm's around in client-core
and allocate from that instead of dynamically allocating one
everytime?
My 2 cents :)
thanks,
Murali
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
