Re: [PATCH] HZ change for ix86

[Dan Kegel <dank@alumni.caltech.edu>]

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/