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

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

Jay Lan wrote:

>Andrew Morton wrote:
>  
>
>>Jay Lan <jlan@engr.sgi.com> wrote:
>> 
>>    
>>
>>>If you can show me how to not sending per-tgid with current patchset,
>>>i would be very happy to drop this request.
>>>   
>>>      
>>>
>>pleeeze, not a global sysctl.  It should be some per-client subscription thing.
>> 
>>    
>>
>
>Per-client subscription is not possible since it is the push (multicast)
>model we
>talk about and delayacct needs tgid.
>  
>
One way to do per-client subscription that Balbir brought up
is to have separate multicast groups for the clients wanting to receive 
per-pid stats and per-tgid stats.

However, this does change the current API since a separate connect to 
the per-tgid multicast group is needed.
So its not a option that can be tagged on later but needs to be done now.

>How about sending tgid stats when the last process in the group exist?
>But do not send it if not the last in the thread?
>
>  
>
This is doable if we have a place where the per-tgid data can be 
accumalated.
One choice that was explored and discarded was to have a struct 
taskstats allocated as part of mm struct,
and keep accumalating per-pid stats into that struct (ie. while filling 
the per-pid stat struct, accumalate into the
per-tgid struct too) which obviously doubles the collection overhead. 
Instead we chose to collect the per-tgid
stats dynamically.

However, we can consider allocating a per-tgid struct as part of the 
exit routine (when we notice a thread exiting
that is part of a thread group) and accumalate stats from each exiting 
thread of that group into the per-tgid stat and
output it alongwith the last exiting thread.

This would also save on the cost of collecting the entire per-tgid data 
each time a thread exits (as is being done now).

This solution is also a bit of an API change since the kind of data 
being received on the common multicast channel
will be different from what it is now. Also looks a little involved.


So we have solutions for the problem going forward, but not without 
changing the API.
Question is: does this really need to be done even in future ? If so, 
then we should perhaps do the change rightaway.

One more point to consider here - if a third or fourth subsystem were to 
come along to use the taskstats
interface and did not want to use the taskstats structure (since they 
have no field in common)...their clients
would still need to be able to accept getting data they don't care about 
(whether they have one or two multicast
groups). So the model for dealing with unwanted data will still need to 
be "don't process the netlink attributes
you don't care about". But thats farther into the future...


--Shailabh