About effective resolution of cpu execution clocks

[Miguel Telleria de Esteban]

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
-----------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121024/984598ba/attachment.bin