Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5

[Al Boldi <a1426z@gawab.com>]

Peter Williams wrote:
> Al Boldi wrote:
> > This is especially visible in spa_no_frills, and spa_ws recovers from
> > this lockup somewhat and starts exhibiting this problem as a choking
> > behavior.
> >
> > Running '# top d.1 (then shift T)' on another vt shows this choking
> > behavior as the proc gets boosted.
>
> But anyway, based on the evidence, I think the problem is caused by the
> fact that the eatm tasks are running to completion in less than one time
> slice without sleeping and this means that they never have their
> priorities reassessed. 

Yes.

> The reason that spa_ebs doesn't demonstrate the
> problem is that it uses a smaller time slice for the first time slice
> that a task gets. The reason that it does this is that it gives newly
> forked processes a fairly high priority and if they're left to run for a
> full 120 msecs at that high priority they can hose the system.  Having a
> shorter first time slice gives the scheduler a chance to reassess the
> task's priority before it does much damage.

But how does this explain spa_no_frills setting promotion to max not having 
this problem?

> The reason that the other schedulers don't have this strategy is that I
> didn't think that it was necessary.  Obviously I was wrong and should
> extend it to the other schedulers.  It's doubtful whether this will help
> a great deal with spa_no_frills as it is pure round robin and doesn't
> reassess priorities except when nice changes of the task changes
> policies.

Would it hurt to add it to spa_no_frills and let the children inherit it?

> This is one good reason not to use spa_no_frills on
> production systems.

spa_ebs is great, but rather bursty.  Even setting max_ia_bonus=0 doesn't fix 
that.  Is there a way to smooth it like spa_no_frills?

> Perhaps you should consider creating a child
> scheduler on top of it that meets your needs?

Perhaps.

> Anyway, an alternative (and safer) way to reduce the effects of this
> problem (while your waiting for me to do the above change) is to reduce
> the size of the time slice.  The only bad effects of doing this is that
> you'll do slightly worse (less than 1%) on kernbench.

Actually, setting timeslice to 5,50,100 gives me better performance on 
kernbench.  After closer inspection, I found 120ms a rather awkward 
timeslice whereas 5,50, and 100 exhibited a smoother and faster response, 
which may be machine dependent, thus the need for an autotuner.

Thanks!

--
Al

-
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/