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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jay Lan wrote:

Andrew Morton wrote:
Jay Lan <[email protected]> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux