Mailinglist Archive: opensuse-kernel (75 mails)

< Previous Next >
Re: [opensuse-kernel] Re: user/sys ticks for process exceed overall user/sys ticks
  • From: Peter Hofer <peter.hofer@xxxxxx>
  • Date: Mon, 03 Mar 2014 19:15:04 +0100
  • Message-id: <2007357.tLipgksbqY@sunflower>
What I'm wondering is why your total's are near the same as a single
user's ticks. I.e. you have 4 cores, shouldn't the total be about 4x
the single
user/single-thread ticks?

----
Silly me -- I should have read the documentation before responding.

Those are not ticks. /proc/stat returns clock-ticks "(Time units are in
USER_HZ (typically hundredths of a second)". Vs. the numbers in
/proc/self/stat are in "jiffies".

I don't think there is an established formula for comparing jiffies & clock
ticks. Has to do with variable CPU clock speeds. You need to use the system
call for getting actual time values back.

Different units of measurement sound like a good explanation. I did read
proc(5), and assumed both /proc/stat and /proc/self/stat times are specified
in clock ticks, since the manpage gives sysconf(_SC_CLK_TCK) as scaling factor
for both.

I looked up relevant parts of the kernel sources today and got the impression
that at least the accounting happens entirely in jiffies. From what I can
gather, account_user_time() in kernel/sched/cputime.c is used to update the
times of the task, the task group and the entire CPU and is always called with
arguments of cputime_one_jiffy and cputime_to_scaled(cputime_one_jiffy). The
cputime_to_scaled() macro doesn't seem to do anything, however.

Next, I looked at do_task_stat() in fs/proc/array.c, where /proc/<pid>/stat
content is generated. The user and system time are obtained via
task_cputime_adjusted(), or thread_group_cputime_adjusted(). From what I can
gather, the latter is used for the entire process. Either way, the returned
values appear to be the ones updated with jiffy counts from
account_user_time(), and converted via cputime_to_clock_t() for output.

show_stat() in fs/proc/stat.c generates the /proc/stat content and prints the
CPU-wide values, updated indirectly from account_user_time(), and also
converts them via cputime_to_clock_t().

I can easily have missed something -- and if I have, please tell me -- but it
seems to me that user and system times from /proc/stat and /proc/pid/stat
should have matching units. My next best guess is that there are things
attributed to the utime/stime of a process which are attributed to different
activities on the CPU level.

However, if there is some system call or library function that gives perfectly
matching per-process and CPU-wide times, I'd be incredibly thankful as well!

More interesting... you are running 8 threads. It's
interesting to see how well python does parallelization.
[...]
Your 8 threads utilize about 1.9 cores.

Interesting! That's probably because of CPython's global interpreter lock
(GIL). I didn't really have full utilization in mind for that script, since
the effect seems to occur whenever there's more than one thread involved.

Python's multiprocessing package should offer better utilization since it
avoids the GIL by spawning processes instead of threads, which in this case
would defeat the purpose of the script.

--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-kernel+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups