After reading over the discussion on HZ values, I decided to do some testing.
My first test was to start up 3 windows of quake2 in X rendering mode. For
anyone that is not already aware, Quake2 is extremely processor intensive. I
ran a timedemo (which runs through a demo as quickly as the processor will
allow) and measured the time for all windows to complete the first demo.
Although they were running along reasonably well synchronized with each other,
quake2's memory footprint is so huge that I suspect that even being a single
frame out of sync would trash the L1 cache and make a pretty good dent in the l2
cache as well. (Quakes footprint is I think mostly data anyway and that is not
considered shared in the cache, right?) Here are the results:
HZ=100 2:12
HZ=1024 2:08
HZ=1024:DEF_PRIORITY=1 2:14
DEF_PRIORITY is defined in linux/include/linux/sched.h and controls the default
maximum timeslice. It defaults to 20 which corresponds to 200ms (which to me is
a long time.). A value of 1 means 10ms timeslices. Setting this value to 1
TOTALLY DESTROYS the functionality of nice, of course. The above numbers
demonstrate that a high HZ or low DEF_PRIORITY do not destroy the performance of
my 300MHZ AMD K6-2 due to overhead. But the numbers don't show the really
important features, which I will get to shortly.
My next test was slightly different. I started one window of quake2 and then
opened another xterm and started 3 tight 'for' loop processes. (written in C,
not shell script ;-) ) and watched the quake display. I then went ahead and
started 7 more of the for loops, noting the performance of the quake window and
the responsiveness of the xterminal. Here are the (subjective but very striking
and obvious) results:
3 for loops 10 for loops
HZ=100 unplayable,jerky totally unplayable
HZ=1024 unplayable,jerky totally unplayable
HZ=1024:DEF_PRIORITY=1 slow, smooth, playable unplayable but much smoother.
When starting the additional 'for loops' the xterm was smooth and had *instant*
response with DEF_PRIORITY=1. It became quite laggy. I would see "[[A" and
that sort of thing sometimes when I would hit up arrow to bring up the previous
command line. I don't think HZ made much diferrence anywhere except *maybe*
speeding up my first test slightly.
My question is, what would have to be done to get the advantages of the lower
DEF_PRIORITY without trashing the implementation of 'niceness'? When I'm not
specifically testing a kernel for performance, I run my system with DEF_PRIORITY
at 1 and have for a year or so. I find that with everything getting serviced
quickly, without long delays between, I don't *need* 'nice' to work.
-Steve
P.S. To change HZ I changed the #DEFINE HZ line in linux/include/asm/param.h .
I hope that is the correct way to do it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/