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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
