Ingo Molnar wrote:
> btw., i think some more consolidation could be done in this area. We've
> now got the traditional /proc/PID/stat metrics, schedstats, taskstats
> and delay accounting and with CFS we've got /proc/sched_debug and
> /proc/PID/sched. There's a fair amount of overlap.
>
Yes. true. schedstats and delay accounting share code and taskstats is
a transport mechansim. I'll try and look at /proc/PID/stat and /proc/PID/sched
and /proc/sched_debug.
> btw., CFS does this change to fs/proc/array.c:
>
> @@ -410,6 +408,14 @@ static int do_task_stat(struct task_stru
> /* convert nsec -> ticks */
> start_time = nsec_to_clock_t(start_time);
>
> + /*
> + * Use CFS's precise accounting, if available:
> + */
> + if (!has_rt_policy(task)) {
> + utime = nsec_to_clock_t(task->sum_exec_runtime);
> + stime = 0;
> + }
> +
> res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
> %lu %lu %lu %lu %lu %ld %ld %ld %ld %d 0 %llu %lu %ld %lu %lu %lu %lu %lu \
> %lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu %llu\n",
>
> if you have some spare capacity to improve this code, it could be
> further enhanced by not setting 'stime' to zero, but using the existing
> jiffies based utime/stime statistics as a _ratio_ to split up the
> precise p->sum_exec_runtime. That way we dont have to add precise
> accounting to syscall entry/exit points (that would be quite expensive),
> but still the sum of utime+stime would be very precise. (and that's what
> matters most anyway)
>
> Ingo
I'll start looking into splitting sum_exec_time into utime and stime
based on the ratio already present in the task structure.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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/
