lkml.org 
[lkml]   [2006]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 <balbir@in.ibm.com> wrote:
    >>
    >>
    >>
    >>> Andrew Morton wrote:
    >>>
    >>>> On Fri, 09 Jun 2006 03:41:04 -0400
    >>>> Shailabh Nagar <nagar@watson.ibm.com> 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
    accounting
    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
    important.
    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.

    Thanks,
    - jay

    >
    > --Shailabh
    >

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

    \
     
     \ /
      Last update: 2006-06-09 20:28    [W:0.030 / U:29.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site