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
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?
>>
>>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?
>
> No other subsystem needs a global knob, does it?
>
> 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?

Another option is to get the package to define their own taskstats genetlink
attribute and fill it up in taskstats_exit_send(). This would be similar to
TASKSTATS_TYPE_AGGR_PID/TGID.

They can make this attribute independent of the taskstats structure and fill
it based on their policy (per-pid or per-tgid). But the current interface
users like CSA want to build on top of the taskstats structure.

>
> 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? If so, has it been quantified?
>


--

Balbir Singh,
Linux Technology Center,
IBM Software Labs
-
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 17:44    [W:0.362 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site