[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.172 / U:0.256 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site