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

[Jay Lan <jlan@sgi.com>]

Shailabh Nagar wrote:
> 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 sounds a good plan. You do allocating a per-tgid struct only once
per thread group, right?

> 
> 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.

I am confused. Wouldn't it simply a change in the test of when to
process and write the tgid data? The API seems to me unchanged? Do
i miss something?

Regards,
  - jay


> 
> 
> 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
>