Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats

[Shailabh Nagar <nagar@watson.ibm.com>]

Jay Lan wrote:

>Jay Lan wrote:
>  
>
>>Shailabh Nagar wrote:
>> 
>>    
>>
>>>Andrew Morton wrote:
>>>
>>>   
>>>      
>>>
>>>>You see the problem - if one userspace package wants the tgid-stats and
>>>>another concurrently-running one does now, what do we do?  Just leave it
>>>>enabled and run a bit slower?
>>>>
>>>>If so, how much slower?  Your changelog says some potential users don't
>>>>need the tgid-stats, but so what?  I assume this patch is a performance
>>>>thing?  If so, has it been quantified?
>>>>  
>>>>     
>>>>        
>>>>
>>>Here are some results from running a simple program (source below) that does
>>>10 iterations of creating and then destroying 1000 threads. On the side, another utility
>>>kept reading the pid (+tgid if present) stats from exiting tasks.
>>>
>>>   
>>>      
>>>
>>I ran my testing using the same program posted by Shalilabh attached in his
>>posting.
>>    
>>
Thanks for running this. The results look interesting.

>>System: SGI a350, a two cpus IA64 machine.
>>Kernel:  2.6.17-rc3 + delay-acct-taskstats patch set
>>      + tgid-disable_patch_shailabh + exit race patch_balbir +
>>csa_patch_jlan
>>
>>I also modified the Decumentation/accounting/getdelay.c:
>>  - it repeatedly does recv() to retrieve data from kernel
>>  - instead of using printf() to display data received, i simply write
>>it to
>>    disk as it would be for an accounting daemon. Note that currently
>>both the
>>    BSD (or GNU) accounting and the CSA writes accounting data from kernel.
>>    As an effort of moving accounting system to userspace, the raw data
>>needs
>>    to be written to a raw file first before further processing.
>>    
>>
In exit_recv.c, you appear to be dumping the per-tgid data  received to 
disk too ?
If the accounting daemon isn't interested in per-tgid, shouldn't it be 
discarding the data immediately after
doing the recv() and only write to disk the data it wants ?
Perhaps I'm missing something.


<snip>

>>Another observation that i considered bad news is that all
>>10 runs produced 1 to 5 recv() error with errno=105 (ENOBUF).
>>    
>>
Wonder if this has to do with userspace not being able to keep up with 
the data flow because
of the pathological rate at which exits happen.

Anyway, lets look at the overhead part first perhaps.

--Shailabh