The time slice doesn't increase when you increase HZ though. The
"default" time slice is set by DEF_PRIORITY in <linux/sched.h>:
#define DEF_PRIORITY (20*HZ/100) /* 200 ms time slices */
This is in ticks. So if you compile with a higher HZ, all the time
slice calculations get scaled up, and the time slice won't actually
change. Thus the two issues above shouldn't be affected.
I don't know what the costs of a higher HZ value might be, except for
the obvious one: more cpu cycles will be spent servicing the timer
interrupt. On my PPro, servicing the timer interrupt takes around 1500
cycles, so with HZ = 100 this accounts for fraction of a percent of
the processor's time. With HZ = 1024, this still wouldn't be much more
than one percent (I expect the figures to be similar for a K6). HZ =
1024 on a 25MHz 386 might well cause the majority of the processor's
time to be spent servicing timer interrupts.
I don't know what the implications are for the caches of increased
frequency of the timer interrupt. The code is small and probably
resides in the L2 cache much of the time, so it's probably
marginal. If someone really wanted to know they could use the
performance monitoring extensions to find out.
Regarding top, there ought to be a way that user-space can find out
the current value of HZ.
-- Dave Wragg
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com