Re: [PATCH] Nick's scheduler policy v12

[Martin J. Bligh]

> I think the two will always related. One means giving a higher
> dynamic priority, the other a bigger timeslice. So you want
> say gcc to have a 100ms timeslice with lowest scheduling prio,
> but X to have a 20ms slice and a very high scheduling priority.

Right.
 
> Unfortunately, the way the scheduler currently works, X might
> use all its timeslice, then have to wait 100ms for gcc to finish
> its. The way I do it is give a small timeslice to high prio tasks,
> and lower priority tasks get progressively less.

If the interactive task uses all it's timeslice, then it's not really
very interactive, it's chewing quite a bit of CPU ... presumably in
the common case, these things don't finish their timeslices. I thought
we preempted the running task when a higher prio one woke up, so this
should still work, right?

So it would seem to make sense to boost the prio of a interactive task 
*without* increasing the size of it's timeslice.

> When _only_ low priority tasks are running, they'll all get long
> timeslices.

That at least makes sense. AFIAK at least the early versions of Con's
stuff make cpu bound jobs' timeslices short even if there were no
interactive jobs. I don't like that (or more relevantly, the benchmarks
don't either ;-)).

> OK well just as a rough idea of how mine works: worst case for
> xmms is that X is at its highest dynamic priority (and reniced).
> xmms will be at its highest dynamic prio, or maybe one or two
> below that.
> 
> X will get to run for maybe 30ms first, then xmms is allowed 6ms.
> That is still 15% CPU. And X soon comes down in priority if it
> continues to use a lot of CPU.

If it works in practice, it works, I guess. I just don't see why X
is super special ... are we going to have to renice *all* interactive 
tasks in order to get things to work properly?

M.

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