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@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org