Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
> 13/07/03 14:53:12, Con Kolivas <[e-mail]> wrote:
> >On Sun, 13 Jul 2003 20:41, Guillaume Chazarain wrote:
> >> Hi Con,
> >>
> >> I am currently testing SCHED_ISO, but I have noticed a regression:
> >> I do a make -j5 in linux-2.5.75/ everything is OK since gcc prio is 25.
> >> X and fvwm prio are 15, but when I move a window it's very jerky.
> >
> >Interesting. I don't know how much smaller the timeslice can be before
> >different hardware will be affected. Can you report what cpu and video
> > card you're using? Unfortunately I don't have a range of hardware to test
> > it on and I chose the aggressive 1/5th timeslice size. Can you try with
> > ISO_PENALTY set to 2 instead?
>
> Pentium3 450, 320 Mo RAM, Voodoo Banshee
>
> 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... ?

> >> And btw, as I am interested in scheduler improvements, do you have a
> >> testcase where the stock scheduler does the bad thing? Preferably
> >> without KDE nor Mozilla (I don't have them installed, and I'll have
> >> access to a decent connection in september).
> >
> >Transparency and antialiased fonts are good triggers. Launcing Xterm with
> >transparency has been known to cause skips. Also the obvious make -j 4
> > kernel compiles, and
> >while true ; do a=2 ; done
> >as a fast onset full cpu hog
>
> Well, I had a hard time at making xmms skip with a transparent
> gnome-terminal. I could easily make xmms skip with this, but it's quite
> artificial.

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. 

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

Con