signal: re-add dead task accumulation stats.

We're going to split the process wide cpu accounting into two parts:

 - clocks; which can take all the time they want since they run
           from user context.

 - timers; which need constant time tracing but can affort the overhead
           because they're default off -- and rare.

The clock readout will go back to a full sum of the thread group, for this
we need to re-add the exit stats that were removed in the initial itimer
rework (f06febc9: timers: fix itimer/many thread hang).

Furthermore, since that full sum can be rather slow for large thread groups
and we have the complete dead task stats, revert the do_notify_parent time
computation.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

1 files changed, 9 insertions, 1 deletions

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 2127e959e0f..2e0646a3031 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -559,7 +559,7 @@ struct signal_struct {
          * Live threads maintain their own counters and add to these
          * in __exit_signal, except for the group leader.
          */
-        cputime_t cutime, cstime;
+        cputime_t utime, stime, cutime, cstime;
         cputime_t gtime;
         cputime_t cgtime;
         unsigned long nvcsw, nivcsw, cnvcsw, cnivcsw;
@@ -568,6 +568,14 @@ struct signal_struct {
         struct task_io_accounting ioac;
 
         /*
+         * Cumulative ns of schedule CPU time fo dead threads in the
+         * group, not including a zombie group leader, (This only differs
+         * from jiffies_to_ns(utime + stime) if sched_clock uses something
+         * other than jiffies.)
+         */
+        unsigned long long sum_sched_runtime;
+
+        /*
          * We don't bother to synchronize most readers of this at all,
          * because there is no reader checking a limit that actually needs
          * to get both rlim_cur and rlim_max atomically, and either one