>>> That is elementary. The running time counts are in JIFFIES,
>>> which are in the HZ units. The 'ps' has 'HZ' compiled in
>>> when it was made. In fact the system does not tell the internal
>>> HZ value out in any easy to use way. So sad.
>>
>> Ah, I see... is there any way for the ps/top/etc. utilities to
>> get at the HZ rate so this behaviour can be fixed?
Yes, it is very hard to keep such a secret.
> It is somewhat difficult to modifying presentation machinery of some
> values in e.g. /proc/123/stat "file" to scale them so that they always
> present their value as if the HZ would be the ``classical constant''
> for given platform. For example, where would the ``classical constant''
> be taken from, if the only instance of ``HZ'' is modified ?
It is almost silly to think that all HZ-based values could be fixed.
It is better to leave them as they are.
> In this case the deprecated sysconf(_SC_CLK_TCK) would be THE answer
> to solve the problems that ps/top/et.al. have.
Long term, I suppose it is. I'm not interested in that now though,
because Linux 2.0 and 2.2 won't support it. The library also has
a totally bogus version, so I'd need to use assembly in procps.
For those that missed it, this problem has been fixed:
http://www.cs.uml.edu/~acahalan/linux/procps-990103.tar.gz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/