[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.026 / U:2.500 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site