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

[Haoqiang Zheng <haoqiang@gmail.com>]

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

Sorry for the late response. I was busy with some other projects.

AFAIK, there are basically two task properties that can affect its
long term CPU allocation: the nice value and the interactiveness. The
nice value affects the time slice value. The interactiveness affects
the time_slice recharge frequency (an interactive task doesn't expire
unless there's an ``expire_starving'').

Well, swap-sched doesn't affect a task's time_slice value, but it does
has impact on interactivity detection. Currently, Linux detects task
interactivity based on ``sleep_average''. With swap-sched, a task with
dependency will sleep less than it does in vanilla kernel. I am not
sure if ``different'' necessary means bad. But I am sure
swap-sched can be modified so that the dependency detection part will
work exactly the same way as vanilla kernel.

Best regards,
Haoqiang