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

Jay Lan
2006-06-12T18:54:08Z

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
>