Messages in this thread | | | From | Guillaume Chazarain <> | Date | Mon, 14 Jul 2003 17:40:04 +0200 | Subject | Re: [RFC][PATCH] SCHED_ISO for interactivity |
| |
14/07/03 02:07:34, Con Kolivas <kernel@kolivas.org> wrote: >On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote: >> Good, with ISO_PENALTY == 2, I can smoothly move big windows (with >> ISO_PENALTY == 5 it was smooth only with very small windows), but it lets >> me move them smoothly during less time than stock :( > >Less time than stock? I don't understand you. You can only move them smoothly >for a small time or they move faster or... ?
With the previous SCHED_ISO, moving big windows was smooth for a short time, but then it became jerky. Unlike with stock where it was smooth all the time.
>Indeed it is artificial, and probably never a real world condition unless it >was specifically an attack, but it would never bring the system to a halt, >just some minor audio hiccups while it adjusted.
This is also true for stock.
>> >The logical conclusion of this idea where there is a dynamic policy >> > assigned to interactive tasks is a dynamic policy assigned to non >> > interactive tasks that get treated in the opposite way. I'll code >> > something for that soon, now that I've had more feedback on the first >> > part. >> >> Interesting, let's see :) >> But as the interactive bonus can already be negative I wonder what use >> will have another variable. > >As it is, the penalty will be no different to what it currently gets to (in >the same way sched_iso get the same bonus they normally would). The >difference is once they are moved to the different policy it is much harder >for them to change from that state, always getting the maximum penalty, and >being expired each time they run out of timeslice instead of getting a chance >to be put onto the active array. Neither of these new states is very >different to what normal policy tasks get except for the fact they dont >change interactive state without a lot more effort.
OK, the latest SCHED_ISO fixed my problem, but now I am afraid of the scheduler trying to be too intelligent, because if it makes the wrong choice the bad result will be much more noticeable. I like the simplicity of stock, the interactivity bonus is given in a simple and understandable way, and if it's not given to the process you want, you can always renice it or make it RT.
I have to admit that p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) / MAX_BONUS; and if ((runtime - MIN_SLEEP_AVG < MAX_SLEEP_AVG) && (runtime * JUST_INTERACTIVE > p->sleep_avg)) p->sleep_avg += (runtime * JUST_INTERACTIVE - p->sleep_avg) * (MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) / MAX_SLEEP_AVG;
are quite obscure to me.
Also, I don't understand your MAX_BONUS definition: ((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100) it evaluates to -15
I would use ((MAX_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100 / 2) since it gives 5.
Guillaume
- 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/
| |