Hi...
On 8/2/09, Greg KH <greg@xxxxxxxxx> wrote:
> The following C program should properly show you the kernel HZ.
>
> thanks,
>
> greg k-h
>
> --------------
>
> #include <unistd.h>
> #include <time.h>
> #include <stdio.h>
>
> int main()
> {
> struct timespec res;
> double resolution;
>
> printf("UserHZ %ld\n", sysconf(_SC_CLK_TCK));
>
> clock_getres(CLOCK_REALTIME, &res);
> resolution = res.tv_sec + (((double)res.tv_nsec)/1.0e9);
>
> printf("SystemHZ %ld\n", (unsigned long)(1/resolution + 0.5));
> return 0;
> }
compiling and linking that code to librt yields:
UserHZ 100
SystemHZ 1000000000
while in fact my system's HZ=300. So I think, in user space's point of
view, exported HZ is always seen as 100. CMIIW. And yes, probably this
value is what user space should care about, not the real HZ in kernel
space.
My personal test about 2 years ago written in unpublished article so
far revealed that unless we deal with very sensitive timing
application such as real time audio encoding or high definition video
playback, HZ=100 or 250 or 1000 (at that time, 300 is still not an
option) yield almost the same perfomance and latency... assuming the
rest of the kernel configurable parameters stay the same (preemption
model, dynamic tick or not etc etc).
--
regards,
Mulyadi Santosa
Freelance Linux trainer
blog: the-hydra.blogspot.com
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
