Re: dynamic sched timeslices

[Kurt Garloff <garloff@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

Hi Andrew,

On Mon, Mar 15, 2004 at 03:40:42PM -0800, Andrew Morton wrote:
> Kurt Garloff <garloff@suse.de> 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.
* Some people are unhappy that nice is not nice enough.

> In
> theory, the scheduler should magically tune itself to the current workload.

No, the computer can not take the decision whether a machine is sitting
in a machine room and mainly doing batch processing or whether it's used
by somebody sitting in front of it as workstation.

You can add heuristics and look at the load and sleep_avg of processes,
and scale timeslices dynamically, but these heuristics are IMVHO a very 
bad idea. They tend to break in subtle ways and disallow to reproduce
benchmark numbers etc.

I do know that the priorites do ensure that interactive processes have
some bonus, so even with long timeslices a system should be usable.
But heuristics fail and some situtaions with high load just can't be 
solved by such bonuses.

> If your patch is indeed necessary then this may point at a bug in the
> current CPU scheduler.

No, why should it? How should the computer know what the user wants if
he has no way to tell him?

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.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]