Re: HZ, preferably as small as possible

[torvalds@transmeta.com (Linus Torvalds)]

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