That would be ideal, but what will you do, when your
applications using current interface need then be
changed. A flag-day ?
> > In this case the deprecated sysconf(_SC_CLK_TCK) would be THE answer
> > to solve the problems that ps/top/et.al. have.
>
> not at all. The problem is that /proc/<pid>/stat (and other kernel
> interfaces) export values that are dependent on the kernel-internal HZ
> definition. They should export 'natural' units like nanoseconds or
> microseconds, this solves the problem once for all, makes binary data
> files exchangable between different-HZ Linux boxes, etc.
Remember, we have binary interfaces, and "ASCII" ones.
For *binary* interfaces usage of structures with nanoseconds
and seconds would be best (assuming at least 32 bits for
both fields), for ASCII ones I would present times as:
12345.98765
placing the "decimal point" to mark how the time is in
seconds, and decimal franctions of it.
Presenting the fractions would be challening, though.
In order of not to loose accuracy in jiffies fraction,
you will want to present the printout with enough digits,
but how you determine the needed scalers ?
#if HZ <= 1000 /* 50, 60, 1000, whatever */
# define HZ_SCALER 1000
# define HZ_SCALER_DIGITS "3"
#elsif HZ <= 10000 /* 1024, etc */
# define HZ_SCALER 10000
# define HZ_SCALER_DIGITS "4"
#elsif HZ <= 100000 /* tock, tock, are you mad ? */
# define HZ_SCALER 100000
# define HZ_SCALER_DIGITS "5"
#else /* HZ > 100 000 ---> you are mad! */
# warning "HZ_SCALER may be too low, but your HZ is way too high!"
# define HZ_SCALER 1000000
# define HZ_SCALER_DIGITS "6"
#endif
sprintf(buf, "%d.%0"HZ_SCALER_DIGITS"d", jiffies / HZ,
((jiffies % HZ)*HZ_SCALER+HZ/2)/HZ);
with back-converting that value to HZ base my test
program (integer math all the way) kept all the time
the difference in between the original "jiffies", and
the back-coverted value in round zero.
Same algorithm can be used to translate 'jiffies'
things to 'nanoseconds', but beware 32-bit overflow
dangers... Perhaps for that reason doing it in
'microseconds' would be sensible (up to HZ=2147,
maybe even up to HZ=4294)
Looking at those expressions above I see well, why
DEC UNIX, and thus Linux/Alpha uses HZ value of
1024, and *not* 1000 ! In fact when changeing to
the scaled interfaces, I would suggest refraining
from using any other HZ values than powers of two:
16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192.
> -- mingo
/Matti Aarnio <matti.aarnio@sonera.fi>
-
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/