Dear all, I resend this question that I posted yesterday in the Linux Real-Time mailing list but received no answers maybe due to its "newbie status". http://marc.info/?l=linux-rt-users&m=135099100016609&w=2 let me rephrase-it for a generic not necessary real-time aware audience: The question concerns the per-process CPU usage statistics maintained by the kernel. As far as I can tell, the only places where this usage counter is stored are in the utime and stime fields of task_struct. http://lxr.linux.no/#linux+v3.6.3/include/linux/sched.h#L1362 (line 1362) I have observed that these fields are of type "cputime_t" which seems to be defined as an unsigned long and therefore contain 32bits (at least in a 32bit architecture such as x86). http://lxr.linux.no/linux+v3.6.3/include/asm-generic/cputime.h#L7 These fields utime and stime are used as accumulators of time usage in the implementation of POSIX CPU-usage clocks and timers. http://lxr.linux.no/#linux+v3.6.3/kernel/posix-cpu-timers.c A typical use-case of this functionality is measuring the CPU time consumed by a thread. In real-time systems this information can be used for further actions such as changing its priority, sending a signal or whatever. Here is an example using NPTL from libc: clockid_t clock; struct timespec before_ts, after_ts, interval; pthread_getcpuclockid( pthread_self(), &clock ); clock_gettime(clock, &before_ts); ... do your things here clock_gettime(clock, &after_ts); interval = timespec_substract(after_ts, before_ts); In this code the time is stored in a struct timespec which is composed of 2 32-bit longs obtaining both a resolution of nanoseconds and a expand of years. On the other side 32bit integers such as utime and stime cannot provide both a high resolution and high time span. And according to the man page of proc, when these fields are output from /proc/<pid>/stat they give the value in jiffies (1/CONFIG_HZ sg, i.e. 4 millisec in most kernel configs). The way clock_gettime works, when linked to a process CPU clock is by keeping a counter of CPU usage updated by the scheduler on every preemption action + using hardware facilities to measure the latest time period. I assume that Linux, specially since the merge of high resolution timers in 2.6.21, benefits now from the latest "hardware facilities for time management" gaining resolutions of micro and nanoseconds, as reported by clock_getres(). With this background in mind I repeat the same questions that I asked in the linux-rt mailing list: * What is the effective resolution of two invocations of clock_gettime() on the same running thread for a long period involving several CPU preemptions? * Are there other fields apart from stime and utime with the sufficient precision to maintain a CPU usage count? * Does the PREEMPT_RT branch improve this resolution somehow? Thanks in advance for your time. Cheers, Miguel Telleria -- ----------------------------------------------------------------------- Miguel TELLERIA DE ESTEBAN Grupo de computadores y tiempo real telleriam ENSAIMADA unican.es Dept. Electrónica y Computadores (change "ENSAIMADA" for @) Universidad de Cantabria http://www.ctr.unican.es Tel trabajo: +34 942 201477 -----------------------------------------------------------------------
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
