O1int 0307021808 for interactivity
PATCH 1/1 O1int 0307021808 for interactivity
This latest patch I'm formally announcing has the base O1int changes so far but includes new semantics for freshly started applications so they can become interactive very rapidly even during heavy load. This addresses the "slow to start new apps" evident in O1int so far.
Please test this one and note given just how rapidly things can become interactive it may have regressions in other settings.
This performs better in all settings than any previous one I've posted in my testing, but hardware differs substantially!
The latest should always be found:
http://kernel.kolivas.org/2.5
Con
include/linux/sched.h +1 -0
@@ -336,6 +336,7 @@ struct task_struct {prio_array_t *array;unsigned long sleep_avg; +unsigned long avg_start;unsigned long last_run;unsigned long policy;
kernel/sched.c +46 -8
101 lines not on this page · raw message
Quoted 7 lines · Con Kolivas
This latest patch I'm formally announcing has the base O1int changes so far but includes new semantics for freshly started applications so they can become interactive very rapidly even during heavy load. This addresses the "slow to start new apps" evident in O1int so far.
Please test this one and note given just how rapidly things can become interactive it may have regressions in other settings.
Without this patch, audio skips horribly when I drag a large window. With it, audio is skipless during window dragging, so I like this patch, whatever it does (maybe you'd like to do a victory lap and re-explain the theory?). It's not perfect: in Mozilla, scrolling through a long page with the mouse still causes skipping.
I'm testing this on a AMD K7 1666 (actual) MHz, 512 MB, VIA VTxxx chipset, Software is 2.5.73+Gnome+Metacity+ALSA+Zinf. Video hardware is S3 ProSavage K4M266, running in unaccelerated VGA mode, 1280x1024x16. Yes, I know audio skips less if video is accelerated, IDE runs in dma, etc, but that's not a real solution to this soft realtime scheduling problem.
Regards,
Daniel
Quoted 6 lines · Daniel Phillips
Quoted 5 lines · Con Kolivas
This latest patch I'm formally announcing has the base O1int changes so far but includes new semantics for freshly started applications so they can become interactive very rapidly even during heavy load. This addresses the "slow to start new apps" evident in O1int so far.
Quoted 6 lines
Quoted 2 lines
Please test this one and note given just how rapidly things can become interactive it may have regressions in other settings.
Without this patch, audio skips horribly when I drag a large window. With it, audio is skipless during window dragging, so I like this patch, whatever it does (maybe you'd like to do a victory lap and re-explain the
Lap complete :) Theory? uh erm it's rather involved but basically instead of working off the accumulated sleeping ticks gathered in ten seconds it works on the accumulated sleeping ticks gathered till it wakes up. It has non linear semantics to cope with the fact that you cant accumulate 10 seconds worth of ticks (for example) if only 10 seconds has passed (likewise for less time). Also idle tasks are no longer considered fully interactive but idle and receive no boost or penalty. Finally they all start with some sleep ticks inherited by their parent as though they have been running for 1 second at least.
Quoted 2 lines
theory?). It's not perfect: in Mozilla, scrolling through a long page with the mouse still causes skipping.
I have (at least) one more trick up my sleeve which might help this, but this time I really do want some time to pass and more people test it (in -mm) before making another change.
Con
Quoted 9 lines · Con Kolivas
Theory? uh erm it's rather involved but basically instead
of working off the accumulated sleeping ticks gathered in ten seconds it works on the accumulated sleeping ticks gathered till it wakes up. It has non linear semantics to cope with the fact that you cant accumulate 10 seconds worth of ticks (for example) if only 10 seconds has passed (likewise for less time). Also idle tasks are no longer considered fully interactive but idle and receive no boost or penalty. Finally they all start with some sleep ticks inherited by their parent as though they have been running for 1 second at least.
I'm still pretty much in the dark after that. It says something about your patch, but it doesn't say much about the problem you're solving, i.e., what's the Context? (pun intended)
Regards,
Daniel
Quoted 11 lines · Daniel Phillips
Quoted 9 lines · Con Kolivas
Theory? uh erm it's rather involved but basically instead
of working off the accumulated sleeping ticks gathered in ten seconds it works on the accumulated sleeping ticks gathered till it wakes up. It has non linear semantics to cope with the fact that you cant accumulate 10 seconds worth of ticks (for example) if only 10 seconds has passed (likewise for less time). Also idle tasks are no longer considered fully interactive but idle and receive no boost or penalty. Finally they all start with some sleep ticks inherited by their parent as though they have been running for 1 second at least.
Quoted 3 lines
I'm still pretty much in the dark after that. It says something about your patch, but it doesn't say much about the problem you're solving, i.e., what's the Context? (pun intended)
Basically? Who gets to preempt who and for how long. The interactivity estimator should decide that the correct task is interactive and get a dynamically higher priority and larger timeslice. Is this what you're asking?
Con
Quoted 9 lines · Con Kolivas
Quoted 3 lines · Daniel Phillips
I'm still pretty much in the dark after that. It says something about your patch, but it doesn't say much about the problem you're solving, i.e., what's the Context? (pun intended)
Basically? Who gets to preempt who and for how long. The interactivity estimator should decide that the correct task is interactive and get a dynamically higher priority and larger timeslice. Is this what you're asking?
I guess what I'm saying is, the problem is far from solved, however your concrete results demonstrate you've got an intuitive grasp of how to go at it. I'd like to dig in and find out what the deep issues are. As I've basically ignored scheduling up to now, including all of the details of Ingo's work, there's some background to fill in. Being lazy, I'd prefer to read somebody's detailed [rfc] instead of going through the process of reverse engineering it myself. I presume I'm not the only one.
Regards,
Daniel