[lkml]   [2006]   [Jun]   [10]   [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
    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
    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...


    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-10 15:07    [W:0.023 / U:86.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site