Messages in this thread | | | Date | Sun, 10 Jan 1999 10:36:58 -0600 | From | Steve Bergman <> | Subject | Re: [PATCH] HZ change for ix86 |
| |
Kurt Garloff wrote:
> > 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/
| |