Re: Changing the clock speed

[Dave Hudson <dave@humbug.demon.co.uk> writes:]

>Has anyone got an opinion about changing the value of HZ to 100 from 20?

A couple of observations.

First, increasing clock frequency to improve timer resolution is the wrong
way to go. As was noted, if you need better resolution, you should use an
interval timer in conjunction with your system clock.

Second, increasing clock frequency to reduce latency between context
switches generally indicates that you should fix your preemption code
instead. With the current kernel, we will preempt immediately (that is, not
wait for next clock interrupt) if a real-time process becomes runnable and
the current process is not real-time. We will similarly preempt if a
"cheated" process becomes runnable and the current process is neither
real-time nor "cheated".

"cheated" is defined as a process which gave up the CPU before his CPU
allocation was consumed, and has been giving the CPU up in this manner for a
certain amount of time into the past. This causes interactive applications
to be responsive in preference to CPU-bound applications. See the "cheated"
flag and queue, as well as the "oink" counter ("oink", in English, refers to
the sound a pig makes :->).

With these two aspects covered (plus or minus a bug fix and tweaking!), are
there any other aspects of system performance which really call for us to up
the clock frequency? As Dave measured, there is a real overhead cost in
taking more interrupts--we should do so only when the alternatives have been
exhausted.

                                                Andy
Received on Tue Feb 14 10:46:08 1995