O12.2int for interactivity
PATCH 1/1 O12.2int for interactivity
I've continued development on the interactivity patches against Ingo's new infrastructure changes.
This is a complete resync of the work so far with changes to suit the nanosecond timing.
Rather than just a changelog, here is a complete list of what this patch does on top of Ingo's :
Interactivity credit determines whether a task is interactive or not and treats them differently during priority changing.
Some #defines are used to help conversion from ns to jiffies, and the tuning knobs have been altered slightly to work with these changes.
Tasks do not earn sleep_avg on their initial wakeup.
User tasks sleeping for a long period get just interactive sleep_avg to stay on the active queue but be unable to starve if they turn into cpu hogs.
Tasks with interactive credit elevate their sleep avg proportionately more as their priority bonus starts dropping off.
Tasks without interactive credit are limited to one timeslice worth of sleep avg as a bonus.
Accumulated sleep_avg of over MAX_SLEEP_AVG starts earning tasks interactive credits.
Run out of sleep_avg makes you lose interactive credits.
On their very first wakeup new forks don't get any sleep_avg bonus.
Only tasks with interactive_credits gain sleep_avg for time waiting on the runqueue.
New forks get the lowest value of sleep_avg compatible with the dynamic priority they will wake up with.
Reverted Ingo's EXPIRED_STARVING definition; it was making interactive tasks expire faster as cpu load increased.
Only user tasks get requeued after TIMESLICE_GRANULARITY, and only if they have at least MIN_TIMESLICE remaining.
Tasks with interactive credit lose proportionately less sleep_avg as their dynamic priority drops.
Using up a full timeslice makes you lose interactive credits.
The patch patch-A3-O12.2int is available against 2.6.0-test2-mm3 here:
Ingo's patch-test2-A3 patch against 2.6.0-test2 is also available there, and a patch-test2-A3-O12.2 to go on top of that is also available.
Please note if you do test the interactivity it would be most valuable if you test Ingo's A3 patch first looking for improvements and problems compared to vanilla _first_, and then test my O12.2 patch on top of it. Hopefully there has been no regression and only improvement in going to Ingo's new infrastructure.
Con
patch-A3-O12.2int against 2.6.0-test2-mm3:
include/linux/sched.h +1 -0
@@ -341,6 +341,7 @@ struct task_struct {prio_array_t *array;unsigned long sleep_avg; +long interactive_credit;unsigned long long timestamp;int activated;
kernel/sched.c +111 -39
250 lines not on this page · raw message
Quoted 2 lines · Con Kolivas
Reverted Ingo's
EXPIRED_STARVINGdefinition; it was making interactive tasks expire faster as cpu load increased.
hm, that bit was needed for fairness, otherwise 'interactive' tasks can monopolize the CPU. [ Have you tried lots of copies of thud.c (and Davide's irman2 with the most evil settings), do they still produce no starvation with this bit restored to the original logic? ]
Ingo
Quoting Ingo Molnar <[email protected]>:
Quoted 10 lines · Con Kolivas
Quoted 3 lines
Reverted Ingo's
EXPIRED_STARVINGdefinition; it was making interactive tasks expire faster as cpu load increased.hm, that bit was needed for fairness, otherwise 'interactive' tasks can monopolize the CPU. [ Have you tried lots of copies of
thud.c(and Davide's irman2 with the most evil settings), do they still produce no starvation with this bit restored to the original logic? ]
Ooh hang on I've not tried lots of copies of thud.c at once. Can't try for a little while though.
Con
Quoted 8 lines · Ingo Molnar
Quoted 2 lines · Con Kolivas
Reverted Ingo's
EXPIRED_STARVINGdefinition; it was making interactive tasks expire faster as cpu load increased.hm, that bit was needed for fairness, otherwise 'interactive' tasks can monopolize the CPU. [ Have you tried lots of copies of
thud.c(and Davide's irman2 with the most evil settings), do they still produce no starvation with this bit restored to the original logic? ]
I tried them aggressively; irman2 and thud don't hurt here. The idle detection limits both of them from gaining too much sleep_avg while waiting around and they dont get better dynamic priority than 17.
Con
Quoted 5 lines · Con Kolivas
Please note if you do test the interactivity it would be most valuable if you test Ingo's A3 patch first looking for improvements and problems compared to vanilla _first_, and then test my O12.2 patch on top of it. Hopefully there has been no regression and only improvement in going to Ingo's new infrastructure.
I'm currently testing both schedulers from Ingo and you on top of 2.6.0-test2-mm3. I'll need a little time to study some annoyances I've seen. For example, I've seen XMMS skipping with patch-A3-O12.2int, altough I've been able to manage to find a way to consistently reproduce them. The Evolution 1.4.4 main window also feels a little "heavy", that is, moving it all along the screen, makes the movement feel jumpy sometimes.
The scheduler seems to be getting in good health, and it's getting smoother with each release. However, I've found that the smoothest scheduler I've seens was O10.
I'll keep you all informed about my experiences with both schedulers.