Re: 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


Attachment: pgpdVagcFicvT.pgp
Description: PGP signature

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