RFA: Changing scheduler quantum (Was: REQUEST: OpenLDAP 2.3.7)

[Bernardo Innocenti <bernie@develer.com>]

Arjan van de Ven wrote:

> On Sun, Sep 18, 2005 at 04:27:38AM +0200, Bernardo Innocenti wrote:
> 
>>It's more meaningful to interpret sched_yield() as "give up the processor,
>>as if the scheduler quantum had expired".
> 
> afaik this is *exactly* what the new sched_yield() does ;)

Oops :-)


>>The scheduler wouldn't normally allow a lower priority process to
>>preempt a high-priority ready process for 30+ ms.  Unless I'm
>>mistaken about Linux's scheduling policy...
> 
> if your quantum is up... all other tasks get theirs of course

I assumed dynamic priorities affected the length of the
quantum, but maybe it just changes the number of times
the process is scheduled wrt other processes, with the
quantum being fixed at 20-30ms.

(...a few seconds later...)

Skimming through sched.c, it seems my first guess was
right: the quantum varies with the priority from 5ms
to 800ms.

The DEF_TIMESLICE of 400ms looks a bit too gross for
most applications and the maximum 800ms is just
ridicolously high.

IIRC, the 7.14MHz 68000 in the Amiga 500 did task-switching
at 20ms intervals, with a negligible performance hit.
Couldn't do much better on today's CPUs?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/