[lkml]   [1998]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: context switch time
    Roland Nagtegaal <> writes:
    > I have a question about this:
    > How high can I put HZ (in /usr/src/linux/include/asm-i386/param.h)
    > before
    > I get a (significant) slow-down because of:
    > - cache misses
    > By this I mean that the current process might heavily use the
    > cache, for instance a multimedia program or game. Then the
    > next process gets the processor and cache, so the former will
    > probably have a cache miss. If HZ is sufficiently low, this
    > problem will not be so bad. But how can I find out what might
    > be the optimal value, of course depending on your processor
    > speed and vendor (AMD,Intel etc.)? I didn't measure any
    > slowdown when putting HZ to 1024 on a K6 200. The computer did
    > get a lot more responsive.
    > Some things break though: top measured 978% processor usage.
    > - context switch overhead
    > How many cycles does Linux take to do a task switch?
    > And what about threads?
    > Is it competitive compared to per example NT 4.0?

    The time slice doesn't increase when you increase HZ though. The
    "default" time slice is set by DEF_PRIORITY in <linux/sched.h>:

    #define DEF_PRIORITY (20*HZ/100) /* 200 ms time slices */

    This is in ticks. So if you compile with a higher HZ, all the time
    slice calculations get scaled up, and the time slice won't actually
    change. Thus the two issues above shouldn't be affected.

    I don't know what the costs of a higher HZ value might be, except for
    the obvious one: more cpu cycles will be spent servicing the timer
    interrupt. On my PPro, servicing the timer interrupt takes around 1500
    cycles, so with HZ = 100 this accounts for fraction of a percent of
    the processor's time. With HZ = 1024, this still wouldn't be much more
    than one percent (I expect the figures to be similar for a K6). HZ =
    1024 on a 25MHz 386 might well cause the majority of the processor's
    time to be spent servicing timer interrupts.

    I don't know what the implications are for the caches of increased
    frequency of the timer interrupt. The code is small and probably
    resides in the L2 cache much of the time, so it's probably
    marginal. If someone really wanted to know they could use the
    performance monitoring extensions to find out.

    Regarding top, there ought to be a way that user-space can find out
    the current value of HZ.

    Dave Wragg

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.021 / U:7.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site