[lkml]   [2006]   [Jun]   [9]   [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:
    > Andrew Morton wrote:
    >> On Fri, 09 Jun 2006 16:21:46 +0530
    >> Balbir Singh <> wrote:
    >>> Andrew Morton wrote:
    >>>> On Fri, 09 Jun 2006 03:41:04 -0400
    >>>> Shailabh Nagar <> wrote:
    >>>>> Hence, this patch introduces a configuration parameter
    >>>>> /sys/kernel/taskstats_tgid_exit
    >>>>> through which a privileged user can turn on/off sending of
    >>>>> per-tgid stats on
    >>>>> task exit.
    >>>> That seems a bit clumsy. What happens if one consumer wants the
    >>>> per-tgid
    >>>> stats and another does not?
    > Then the tgid stat sending on exit will need to be turned on for
    > everyone.

    I guess that is the limitation of taskstats. One multicast socket for
    every listeners.

    >>> For all subsystems that re-use the taskstats structure from the exit
    >>> path,
    >>> we have the issue that you mentioned. Thats because several
    >>> statistics co-exist
    >>> in the same structure. These subsystems can keep their tgid-stats
    >>> empty by not
    >>> filling up anything in fill_tgid() or using this patch to
    >>> selectively enable/disable
    >>> tgid stats.
    >>> For other subsystems, they could pass tgidstats as NULL to
    >>> taskstats_exit_send().
    >> I don't understand. If a subsystem exists then it fills in its slots in
    >> the taskstats structure, doesn't it?
    > It can choose not to, by not inserting its "fill my fields" function
    > inside the do..while_each_thread
    > loop within fill_tgid. So while they would still necessarily receive
    > the per-tgid taskstats struct on exit
    > (because some other subsystem needs it), they can atleast save on
    > filling up their part of the struct
    > if they don't need it.
    >> No other subsystem needs a global knob, does it?
    > I didn't understand.
    >> You see the problem - if one userspace package wants the tgid-stats and
    >> another concurrently-running one does now, what do we do? Just leave it
    >> enabled and run a bit slower?
    > Yes, thats what will have to be done. If one user wants, all users
    > will need to get the stats. They can
    > limit their impact by not processing the parts of the netlink message
    > that correspond to the per-tgid stats
    > (since the per-tgid stats are sent as a separate attribute, thats easy
    > to do).
    > This patch covers the use case where someone like CSA is the only user
    > (delay accounting is turned off)
    > and wants to reduce the performance impact of the kernel allocating,
    > sending and userspace discarding
    > the per-tgid stats.
    >> If so, how much slower? Your changelog says some potential users don't
    >> need the tgid-stats, but so what? I assume this patch is a performance
    >> thing?
    > Yes, its a performance optimization.

    Well, for every task exists, two sets of data (of struct taskstats) would
    be sent from kernel: one is the stats for the pid, the other is the
    up-to-current stats for the thread (tgid).

    Strictly speakly, the second set of data is not per-task stats. For
    subsystems that do not use thread as aggregation, 50% of the data from
    the kernel is useless. The option to not sending thread data is very
    Of course we are betting a customer site does not run two different
    application on the same system.

    >> If so, has it been quantified?
    > No :-(
    > Will try to get some numbers.
    > Jay/Chris, if you can try to do that too, for the kind of usage that
    > is typical of CSA,
    > that would be great.

    Probably not until some time next week. But as i point out, 50% of
    traffic is
    not useful to CSA.

    - jay

    > --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-09 20:28    [W:0.029 / U:0.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site