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/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
