Andrew Morton wrote:
On Fri, 09 Jun 2006 16:21:46 +0530
Balbir Singh <[email protected]> wrote:
Andrew Morton wrote:
On Fri, 09 Jun 2006 03:41:04 -0400
Shailabh Nagar <[email protected]> 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.
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.
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.
--Shailabh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
