Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats

[Jay Lan <jlan@engr.sgi.com>]

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/