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

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: [RFC] cfq: adapt slice to number of processes doing I/O
    ... In the patch, if there are more than 3 processes performing concurrent ... I/O, we scale the time slice down proportionally. ... version of the ideal number of bytes the given priority should have ...
    (Linux-Kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... 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. ... 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. ...
    (Linux-Kernel)
  • Re: Multicores
    ... > Skybuck Flying wrote: ... time slice intervals have only a little to do with system ... Give an application a higher priority and it's threads will get a ... The threads of the high priority application will get longer time slices. ...
    (comp.arch)