[Pvfs2-developers] threaded client-core and the device thread

[Walter B. Ligon III]

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
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

-- 
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University