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
adam@yggdrasil.com \ / 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 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/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:16 EST