![]() | |||||||||||||
Messages in this thread |
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-05-11 06:27 [from the cache] ©2003-2008 | |||||||||||||