Cyril Roelandt, le Fri 19 Oct 2012 00:42:12 +0200, a écrit :
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 ?
No, because of this:
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.
The problem we have is that a lot of tools don't call
sysconf(_SC_CLK_TCK_), but actually hardcode 100. That is why a
compatibility mode was introduced for them, but it's independent from
the _SC_CLK_TCK value, thus the confusion. Ideally we fix all users of
/proc which hardcode 100, and then we can get rid of the -c option.
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 ?
It's for efficiency. To give a correct user/system answer, procfs would
have to to through all processes, which would be slow. Until somebody
implements an interface to get the information from the kernel, that's
the best we can get efficiently.