Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: HZ, preferably as small as possible | Date | Mon, 15 Jul 2002 05:15:50 +0000 (UTC) |
| |
In article <Pine.LNX.3.96.1020711162333.5732C-100000@gatekeeper.tmr.com>, Bill Davidsen <davidsen@tmr.com> wrote: >On Thu, 11 Jul 2002, Martin Dalecki wrote: > >> vmstat.c: >> >> hz = sysconf(_SC_CLK_TCK); /* get ticks/s from system */ >> >> And yes I know the libproc is *evil* in this area. >> The rest should be an implementation detail of sysconf(). > >Yes, any of the changes need to make the dynamic value available to >programs.
No they don't.
Have people looked at the 2.5.x patches?
CLK_TCK is 100 on x86. As it has always been. User land should never care about whatever random value the kernel happens to use for the actual timer tick at that particular moment. Especially since the kernel internal timer tick may well be variable some day.
The fact that libproc believes that HZ can change is _their_ problem. I've told people over and over that user-level HZ is a constant (and, on x86, that constant is 100), and that won't change.
So in current 2.5.x times() still counts at 100Hz, and /proc files that export clock_t still show the same 100Hz rate.
The fact that the kernel internally counts at some different rate should be _totally_ invisible to user programs (except they get better latency for stuff like select() and other timeouts).
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |