On Fri, 09 Jun 2006 16:21:46 +0530Then the tgid stat sending on exit will need to be turned on for everyone.
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 parameterThat seems a bit clumsy. What happens if one consumer wants the per-tgid
/sys/kernel/taskstats_tgid_exit
through which a privileged user can turn on/off sending of per-tgid stats on
task exit.
stats and another does not?
It can choose not to, by not inserting its "fill my fields" function inside the do..while_each_threadFor 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?I didn't understand.
You see the problem - if one userspace package wants the tgid-stats andYes, thats what will have to be done. If one user wants, all users will need to get the stats. They can
another concurrently-running one does now, what do we do? Just leave it
enabled and run a bit slower?
If so, how much slower? Your changelog says some potential users don'tYes, its a performance optimization.
need the tgid-stats, but so what? I assume this patch is a performance
thing?
If so, has it been quantified?No :-(