Re: #define HZ 1024 -- negative effects?

From: Adam J. Richter (
Date: Thu Apr 26 2001 - 13:19:23 EST

        I have not tried it, but I would think that setting HZ to 1024
should make a big improvement in responsiveness.

        Currently, the time slice allocated to a standard Linux process
is 5*HZ, or 50ms when HZ is 100. That means that you will notice
keystrokes being echoed slowly in X when you have just one or two running
processes, no matter how fast your CPU is, assuming these processes
do not complete in that time. Setting HZ to 1000 should improve that
a lot, and the cost of the extra context switches should still be quite
small in comparison to time slice length (a 1ms time slize = 1 million
cycles on a 1GHz processor or a maximum of 532kB of memory bus
utilization on a PC-133 bus that transfer 8 bytes on an averge of every
two cycles based to 5-1-1-1 memory timing).

        I would think this would be particularly noticible for internet
service providers that offer shell accounts or VNC accounts (like
WorkSpot and LastFoot).

        A few of other approaches to consider if one is feeling
more ambitious are:
        1. Make the time slice size scale to the number of
           currently runnable processes (more precisely, threads)
           divided by number of CPU's. I posted something about this
           a week or two ago. This way, responsiveness is maintained,
           but people who are worried about the extra context switch
           and caching effects can rest assured that this shorter time slices
           would only happen when responsiveness would otherwise be bad.
        2. Like #1, but only shrink the time slices when at least
           one of the runnable processes is running at regular or high
           CPU priority.
        3. Have the current process give up the CPU as soon as another
           process awaiting the CPU has a higher current->count value.
           That would increase the number of context switches like
           increasing HZ by 5X (with basically the same trade-offs),
           but without increasing the number of timer interrupts.
           By itself, this is probably not worth the complexity.
        4. Similar to #3, but only switch on current->count!=0 when
           another process has just become unblocked.
        5. I haven't looked at the code closely enough yet, but I tend
           to wonder about the usefulness of having "ticks" when you have
           a real time clock and avoid unnecessary "tick" interrupts by
           just accounting based on microroseconds or something. I
           understand there may be issues of inaccuracy due to not knowing
           exactly where you are in the current RTC tick, and the cost
           of the unnecessary tick interrupts is probably pretty small.
           I mention this just for completeness.

Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:16 EST