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

[Walter B. Ligon III]

Good.  I'm making progress tracking down the problems in the code - 
somehow a bunch of edits got lost.  I'm fixing them.  Involves changes 
it all of the client state machines.


BTW, there is one I'm confused about.  src/client/sysint/sys-getattr.sm
the last state action  "getattr_set_sys_response"  returns from several 
places.  It is not clear if ALL of them intend to terminate since they 
don't all set the op_completed flag, but the only option in the SM is to 
terminate.  So I'm assuming they want to terminate.  If you know 
anything about that one I'd appreciate it if you'd look.

Walt

Sam Lang wrote:
> 
> 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
>>> 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
>>

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