[lkml]   [2006]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
Shailabh Nagar wrote:
> Jay Lan wrote:
>> Andrew Morton wrote:
>>> Jay Lan <> 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?

- 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-12 20:56    [W:0.206 / U:2.636 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site