Re: [PATCH] HZ change for ix86

Dan Kegel (dank@alumni.caltech.edu)
Thu, 07 Jan 1999 09:56:39 -0800

Egil Kvaleberg schrieb:
> IMHO, the right thing would be to implement CLK_TCK properly as a true
> reflection of HZ. Now, it seems to be fixed: e.g. 100 for i386, and 1024
> for alpha.
>
> The easiest approach would be to make "timebits.h" pick up HZ from the
> kernel, thus:
> #include <asm/param.h>
> #define CLK_TCK HZ
> The downside is of course that programs would need to be recompiled for any
> change in HZ.
> The best thing would be to fix CLK_TCK at runtime.
e.g.
#define CLK_TCK new_function_to_get_HZ()
> But could this possibly break anything?

Yes, it would break user programs that were compiled before your change.
I know of two ways for user code to access system time right now:
clock() and times(). Both of these have constants (CLOCKS_PER_SECOND and
CLK_TCK)
that can't be changed without breaking user applications.
IMHO we need to leave those alone. I don't want to have to recompile my apps
to move them from 2.0.36 to 2.2.0. (I do like the idea of changing
HZ to a power-of-two multiple of CLK_TCK.)

Maybe we should create a new interface for user applications to get the true
system time in its native units, with the value of the native tick available
at runtime only. e.g. long sys_ticks(), long sys_ticks_per_second().
- Dan

-- 
Speaking only for myself, not for my employer


-
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/