> > So again, the HZ value is the rate at which the CPU will get stolen
> > from YOU. This makes a trade-off necessary to consider rather than
> > "more slices/second is better". There is a lot to consider.
>
An example of a situation that I have looked at is running something very time
sensitive, like "Quake II" on a machine that is also running other things which
may be processor intensive. This is not off in left field. I used to
administer a linux box at a night club which provided games like Quake, and
internet access through netscape, to the club patrons while simultaneously
handling the club's music (on a second sound card) from a large bank of mp3
files run from a terminal in the DJ booth or the cash register terminals, and
ran the point of sale as well as Quicken under dosemu. This kind of thing
requires quick response or you get jerky games and 'skips' in the music. In the
past (and in the above example) I have had excellent results setting
DEF_PRIORITY in include/linux/sched.h to 1. It defaults to 20. The messes up
all the niceness stuff but results in *absolutely silky smooth performance*,
whereas the default value can be quite jerky. I was hoping that a higher HZ
value would accomplish the same thing without destroying nice's behavior. In
the one simple test that I have tried, with HZ=1024, I ran several instances of
a program with simply runs a long 'for' loop. The I started another instance
which actually writes out the numbers that it is counting. The level of
jerkiness in the output seems the same whether HZ=100 or HZ=1024.
I have also in the past done some simple testing to see how the DEF_PRIORITY=1
affects overall performance. Using the same "counting" program, I started
several instances and timed their progress and compared the results with
DEF_PRIORITY=20. There was very little difference and the difference was
actually very slightly in favor of the lower value (or possibly not
statistically significant). I realized later that this did not test the effect
of changing contexts on the L1 and L2 caches.
-Steve
-
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/