Re: dynamic sched timeslices

Con Kolivas
2004-03-16T13:14:06Z

On Tue, 16 Mar 2004 10:36 pm, Kurt Garloff wrote:
> On Mon, Mar 15, 2004 at 03:40:42PM -0800, Andrew Morton wrote:
> > Your patch didn't come with any subjective or measured testing results.

> We've done some measurements with 2.4 and O(1):
> * HZ=1000 cost about 1.5% perf. on a kernel compile (plus problems
> with lost timer ticks)
> * Seting the scheduling timeslices from 1ms--30ms rather than 10ms thr
> 300ms cost another ~3% kernel compile performance
> * Depending on the workload the effect can be larger. Numbercrunching
> would come to mind.

2.4 O(1) effects do not directly apply with 2.6

Dropping Hz will save you performance for sure on 2.6.

Changing the timeslices in 2.6 will be disappointing, though. Although the
apparent timeslice of nice 0 tasks is 102ms, interactive tasks round robin at
10ms. If you drop the timeslice to 10ms you will not improve the interactive
feel but you will speed up expiration instead which will almost certainly
worsen interactive feel. If you drop timeslices below 10ms you will get
significant cache trashing and drop in performance (which your 2.4 results
confirm).

Increasing timeslices does benefit pure number crunching workloads. The
benchmarking I've done using cache intensive workloads (which are the most
likely to benefit) show you are chasing diminishing returns, though. You can
mathematically model them based on the fact that keeping a task bound to a
cpu instead of shifting it to another cpu on SMP saves about 2ms processing
time on P4. Suffice to say the benefit is only worth it if you do nothing but
cpu intensive things, and becomes virtually insignificant beyond 200ms. On
other architecture with longer cache decays you will benefit more;
arch/i386/mach-voyager seems the longest at 20ms.

>It's a classical throughput vs. latency tradeoff and the patch allows
>the user to set it. I'm sure some people are willing to have long
>timeslices in order to gain 5% and don't care about the sched latencies.

As you can see from the above it is not that clear cut.

Con