lkml.org 
[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:49    [W:6.020 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site