On 10/15/2012 02:46 AM, Samuel Thibault wrote:
Hello, Cyril Roelandt, le Tue 09 Oct 2012 03:21:36 +0200, a écrit :$ ./getter&& ./procinfo&& ./task_info System 1900, User 300 System 192000, User 300 System 0, User 0task_info is not surprising: see the error you are getting: you can not directly get the task info from the kernel without being privileged. With privileges, you get the same as procinfo. As pino suggested, getter probably doesn't include the idle task.
OK.
$ head -1 /proc/stat cpu 2884 0 0 195460 0 0 0 0 0Note that this is in ticks, not in seconds, and procfs does not currently accounts system mode (see the source code), it's all taken as user mode.
OK. In "man 5 proc", I can read that this is "measured in units of USER_HZ (1/100ths of a second on most architectures, use sysconf(_SC_CLK_TCK_) to obtain the right value)".
On GNU/Linux, sysconf(_SC_CLK_TCK_) returns 100, so the time spent in user mode would be 2884 ticks (if we use the values from my example), which is 2884/100 = 28.84 seconds.On Hurd, sysconf(_SC_CLK_TCK) returns 1000000, so, does that mean that the time spent in user mode is roughly zero ?
On my machine, /hurd/procfs is launched with the "-c" option (Linux compatible) which forces the translator to use 100 as the number of ticks per second, rather than calling sysconf(_SC_CLK_TCK_). But one just cannot easily retrieve this value. I must admit I'm a bit confused.
About the procfs code: it does take everything as user time. If we look at rootdir.c, the user time displayed in /proc/stat is simply (uptime - idle time). In process.c, though, both system time and user time are taken into account for /proc/<pid>/stat files. Isn't that a bit weird ?
Cyril.