Peter Williams wrote:
> Al Boldi wrote:
> > But how does this explain spa_no_frills setting promotion to max not
> > having this problem?
>
> I'm still puzzled by this. The only thing I can think of is that the
> promotion mechanism is to simple in that it just moves all promotable
> tasks up one slot without regard for how long they've been on the queue.
> Doing this was a deliberate decision based on the desire to minimize
> overhead and the belief that it wouldn't matter in the grand scheme of
> things. I may do some experimenting with slightly more sophisticated
> version.
>
> Properly done, promotion should hardly ever occur but the cost would be
> slightly more complex enqueue/dequeue operations. The current version
> will do unnecessary promotions but it was felt this was more than
> compensated for by the lower enqueue/dequeue costs. We'll see how a
> more sophisticated version goes in terms of trade offs.
Would this affect the current, nearly perfect, spa_no_frills rr-behaviour w/
its ability to circumvent the timeslice problem when setting promo to max?
> >> 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?
>
> The principal determinant would be the smoothness of the yardstick.
> This is supposed to represent the task with the highest (recent) CPU
> usage rate per share and is used to determine how fairly CPU is being
> distributed among the currently active tasks. Tasks are given a
> priority based on how their CPU usage rate per share compares to this
> yardstick. This means that as the system load and/or type of task
> running changes the priorities of the tasks can change dramatically.
>
> Is the burstiness that you're seeing just in the observed priorities or
> is it associated with behavioural burstiness as well?
It's behavioural, exhibited in a choking style, like a jumpy mouse move
during ia boosts.
> >> Perhaps you should consider creating a child
> >> scheduler on top of it that meets your needs?
> >
> > Perhaps.
>
> Good. I've been hoping that other interested parties might be
> encouraged by the small interface to SPA children to try different ideas
> for scheduling.
Is there a no-op child skeleton available?
> One thing that could be played with here is to vary the time slice based
> on the priority. This would be in the opposite direction to the normal
> scheduler with higher priority tasks (i.e. those with lower prio values)
> getting smaller time slices. The rationale being:
>
> 1. stop tasks that have been given large bonuses from shutting out other
> tasks for too long, and
> 2. reduce the context switch rate for tasks that haven't received bonuses.
>
> Because tasks that get large bonuses will have short CPU bursts they
> should not be adversely effected (if this is done properly) as they will
> (except in exceptional circumstances such as a change in behaviour)
> surrender the CPU voluntarily before their reduced time slice has
> expired. Imaginative use of the available statistics could make this
> largely automatic but there would be a need to be aware that the
> statistics can be distorted by the shorter time slices.
>
> On the other hand, giving tasks without bonuses longer time slices
> shouldn't adversely effect interactive performance as the interactive
> tasks will (courtesy of their bonuses) preempt them.
I couldn't agree more. Tackling the problem on both fronts (prio/tslice) may
give us more control, which could result in a more appropriate / fairer /
smoother scheduler.
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]
