Balbir Singh wrote:Actually its both, at this time. Preference is for packages to use taskstats unless they have absolutely
Andrew Morton wrote:
On Fri, 09 Jun 2006 16:21:46 +0530Another option is to get the package to define their own taskstats
Balbir Singh <balbir@xxxxxxxxxx> wrote:
Andrew Morton wrote:I don't understand. If a subsystem exists then it fills in its slots in
On Fri, 09 Jun 2006 03:41:04 -0400For all subsystems that re-use the taskstats structure from the exit
Shailabh Nagar <nagar@xxxxxxxxxxxxxx> wrote:
Hence, this patch introduces a configuration parameterThat seems a bit clumsy. What happens if one consumer wants the
/sys/kernel/taskstats_tgid_exit
through which a privileged user can turn on/off sending of
per-tgid stats on
task exit.
per-tgid
stats and another does not?
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().
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?
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.
That was my question to you from the beginning: do you propose a common
interface based on taskstats or genetlink?
If CSA defines its own taskstats genetlink attirbute, does it listen toVery true. The use of a common taskstats ensures that no duplication needs to occur and as long
the same socket as delayacct? If yes, then the socket will be jammed with
duplicate information before long.
Is it an option to make per-tgid data a unicast? Ie, your daemonThat option already exists (daemon can do a GET of per-tgid stats).
periodically
polling the per-tgid stats?
Thanks,
- jay
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?