Op donderdag 18 januari 2007, schreef Joe Shaw:
Hi again, On Thu, 2007-01-18 at 14:20 -0500, Joe Shaw wrote:choosing another scheduling policy (like sched_batch) is a bit better, as a sched_batch process will use 0% cpu in presence of another process trying to get 100% cpu.I looked into this today, and this isn't how the SCHED_BATCH policy works on Linux (at least with 2.6.20). Indeed doing so would cause an issue with priority inversion, since a blocked process could hold some resource while another process spun. SCHED_BATCH simply drops the sleep interval calculation, which determines the bonus (between -5 and +5) on top of your nice value, and automatically gives your process a -5 bonus.Oops, sorry, typo. I meant it would automatically get a +5 bonus. So, to recap... :) Something run with SCHED_BATCH at nice 0 would act as though it were run at +5. With SCHED_OTHER it would be anywhere from -5 to +5 depending on interactivity. SCHED_BATCH is a bad name considering the older (inversion-prone) implementation. A better name would be SCHED_FIXED.
didn't SCHED_BATCH get some improvements 2 or 3 kernels ago? or that might have been the sched_fixed you mention :D tought the priority inversion thing was solved through increasing the sched_batch priority to normal during the time it holds a lock... anyway, i know sched_batch mostly from the -ck kernel (staircase cpu scheduler) and there it has the previously described behaviour. afaik that's what mainline also is supposed to have, but i'm not sure about that. still, even in mainline sched_batch doesn't dynamically increase or decrease priority, which is better, esp combined with nice +19.
Joe
/Jos
Attachment:
pgpBN8sYkuZsT.pgp
Description: PGP signature