Re: [Tracker] Indexers comparison



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]