Re: context switch time

David Wragg (dpw@doc.ic.ac.uk)
Wed, 22 Apr 1998 01:30:30 +0100

Roland Nagtegaal <roland@powerstar.nl> 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 majordomo@vger.rutgers.edu