=46reitag, 16. M=E4rz 2007 wrote Mike Galbraith:
quoted text
> On Sat, 2007-03-17 at 08:13 +1100, Con Kolivas wrote:
> > On Saturday 17 March 2007 02:34, Mike Galbraith wrote:
> > > On Sat, 2007-03-17 at 00:40 +1100, Con Kolivas wrote:
> > > > Here are full patches for rsdl 0.31 for various base kernels. A full
> > > > announce with a fresh -mm series will follow...
> > > >
> > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.20.3-rsdl-0.31=
=2Ep
quoted text
> > > >atch
> > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-sched-r=
sd
quoted text
> > > >l-0. 31.patch
> > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsd=
l-
quoted text
> > > >0.31 .patch
> > >
> > > It still has trouble with the x/gforce vs two niced encoders scenario.
> > > The previously reported choppiness is still present.
> > >
> > > I suspect that x/gforce landing in the expired array is the trouble,
> > > and that this will never be smooth without some kind of exemption.  I
> > > added some targeted unfairness to .30, and it didn't help much at all.
> > >
> > > Priorities going all the way to 1 were a surprise.
> >
> > It wasn't going to change that case without renicing X.
>
> Con.  You are trying to wedge a fair scheduler into an environment where
> totally fair simply can not possibly function.
>
> If this is your final answer to the problem space, I am done testing,
> and as far as _I_ am concerned, your scheduler is an utter failure.
>

I can not let this comment stay like that. I have an AMD X2 4400+ Dual Core=
=20
running Gentoo and now kernel 2.6.21-rc3 with RSDL 0.30 (HZ=3D300).
Up till now whenever I wanted to watch a movie i had to stop compiling with=
=20
more than one task for the movie to run without skips. When playing games i=
=20
have to renice the game (-15-) or else it would get 'choppy'.
With the new RSDL i compile packages with -j3 (reniced to 15), my wife lets=
 up=20
to 8 computations (scientific computations) running at the same time and th=
e=20
game and a movie still run without any visible flaws. The only thing i saw=
=20
till now was that the mouse cursor was a little less responsive and scrolli=
ng=20
in firefox took a little longer. But amarok for music, the movie in mplayer=
,=20
the 3d game, everything went smooth though a load of > 11. This all without=
=20
even renicing anything but the compiles. With mainline kernel already=20
watching a movie with this load was impossible.
I used the staircase scheduler before RSDL but even with staircase such=20
overload was not possible while watching a movie.
Mike, maybe use higher nice levels for your encoders or just use one. Or ma=
ybe=20
scheck your memory, i guess if the memory bandwidth is too low there's no=20
scheduler which can foresee such thing and react accordingly. Since you hav=
e=20
a HT system it's just one physical ALU, so everything has to be squeezed on=
to=20
this one ALU, up to a certain degree it works, but not forever. And the lam=
e=20
encoders i suppose won't wait that very much and long for their data to get=
=20
delivered from memory so they'll utilize the ALU quite a lot.
Con, continue your scheduler development as it helps many cases which were =
not=20
possible otherwise. I'm amazed of the ability of the scheduler to handle a =
5=20
times overloaded system without too much hazzle.
Great work Con.

Dirk.

PS: Con, don't stress your neck too much, your health is the only thing you=
=20
have to keep for live.