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

From: Balbir Singh
Date: Fri Jun 09 2006 - 11:40:39 EST


Andrew Morton wrote:
On Fri, 09 Jun 2006 16:21:46 +0530
Balbir Singh <balbir@xxxxxxxxxx> wrote:


Andrew Morton wrote:

On Fri, 09 Jun 2006 03:41:04 -0400
Shailabh Nagar <nagar@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/