Re: [RFC PATCH] swap-sched: schedule with dynamic dependency detection (2.6.12-rc3)

[Con Kolivas]

On Mon, 9 May 2005 13:56, Haoqiang Zheng wrote:
> On 5/8/05, Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> > Ok so how does it respond to process_load in contest?
>
> Based on my measurements, the "process_load" processes run at a
> dynamic priority of 115--122.  Which is also pretty much the dynamic
> priority range of the gcc processes.  At a certain point, the vanilla
> Linux scheduler may select either a process_load process or a gcc/make
> process to run, depending on which current runnable task has the
> highest dynamic priority.
>
> With swap-sched enabled, the virtual runnable tasks (tasks that are
> blocked because of waiting for another task) are kept in runqueue.
> For example, if a contest process_load task A with prio 115 blocks on
> waiting for another contest task B with prio 122, task A will remain
> in runqueue.  Task A may be selected by the vanilla scheduler to run
> since it has a high priority. On noticing that A is a virtual runnable
> task, swap-sched further select B to run in place of A. So in the end,
> B will be select to run. Without swap-sched, A will be removed from
> the runqueue once it's blocked, and task B can hardly get a chance to
> run since it has a low priority. That's why at
> http://swap-sched.sourceforge.net/node9.html, process_load has a much
> higher LCPU% when swap-sched is enabled.

While your swap-sched allows tasks waiting on other tasks to run better, it 
also introduces a greater degree of unfairness in cpu resource sharing. By 
allowing the dependent tasks to stay on the runqueue you increase 
substantially their share of the resources they would otherwise have gotten. 
The whole point of decrementing priority and runqueue expiration is to 
maintain fairness and you're introducing another way to delay that system 
from working. process_load is not the ideal task to test this unfairness on 
this design but even that shows twice as much cpu usage with your own tests. 
How do you propose to ensure we maintain fairness in this model ?

Cheers,
Con

Attachment: pgp00000.pgp
Description: PGP signature