On Fri, 20 Jun 2003 07:32, Andreas Boman wrote:
> On Thu, 2003-06-19 at 12:50, Con Kolivas wrote:
> > On Fri, 20 Jun 2003 02:42, Andreas Boman wrote:
> > > On Thu, 2003-06-19 at 12:06, Con Kolivas wrote:
> > > > On Fri, 20 Jun 2003 02:02, Con Kolivas wrote:
> > > > > On Fri, 20 Jun 2003 01:47, Mike Galbraith wrote:
> > > > > > At 12:05 AM 6/20/2003 +1000, Con Kolivas wrote:
> > > > > > >Testers required. A version for -ck will be created soon.
> > > > > >
> > > > > > That idea definitely needs some refinement.
> > > > >
> > > > > Actually no it needs a bugfix even more than a refinement!
> > > > >
> > > > > The best_sleep_decay should be 60, NOT 60*Hz
> > > >
> > > > Here's a fixed patch.
> > >
> > > Ok, that doesnt really seem to change behavior much (from just a little
> > > testing). I can still easily starve xmms by moving a window around over
> > > mozilla or evolution (I suspect for thoose that use nautilus to draw
> > > the desktop that would happen on an 'empty' desktop too..).
> > >
> > > With 2.5.72-mm1, HZ 1000 and MAX_SLEEP_AVG 2 that does *not* happen,
> > > even with a cpu hog running (mpeg2enc) or during make -j20. However
> > > with this kernel, after having moved a window around madly for a while
> > > the mouse pointer is very laggy/jerky for atleast 30 sec after i
> > > release the window (not so with your patch).
> > >
> > > I'm not hitting swap at all, so thats not a factor here.
> >
> > Ok well next thing to try is max_sleep_avg 2*HZ with my patch, possibly
> > with best_sleep_decay 10
>
> Ok, 2.5.72-mm2 + your patch + rml's setscheduler fix,  MAX_SLEEP_AVG
> 2*HZ, BEST_SLEEP_DECAY 10, HZ 1000
>
> This kernel is acting pretty good, I can still starve xmms if I start
> wiggeling a window around right about when a song changes in xmms, but
> it seems to get a timeslice in <20 sec while I'm still wiggeling the
> thing around (this is with make -j20 running as well). Repainting
> windows (evolution -its the slowest app to repaint, and the one its
> easiest to starve xmms with) post-wiggle sometimes takes while, not too
> bad on the whole though.
>
> The mouse pointer isn't all laggy post-window-wiggle like it was with
> -mm1, HZ 1000, MAX_SLEEP_AVG 2*HZ
>
> I have managed to get a few xmms skips when switching desktops (still
> with make -j20 running), but its pretty rare and not at all as
> predictable as it was without your patch (usually takes a few quick
> desktop changes within the first few seconds of playtime).
>
> I may have seen some strangeness while doing concurrent builds and
> similar things (make in linux tree, rpmbuild -ba mozilla.spec for
> example), the bunzip2 of the mozilla tree seemed to take _very_ long,
> and I'm not sure how the fairness is between theese processes now.. (I'm
> wondering if that may be something contest would be able to measure?)

The resolution of results in contest is not up to telling us that I'm afraid. 

> Playing a mpeg movie in mplayer (windowed or fullscreen) while doing the
> concurrent kernel and mozilla builds works just great without any
> noticable framedrops, and no sound skips.
>
> Doing the 'mad window wiggle' with the mplayer window (over evolution)
> will evenually cause some audio skips and/or frame drops, and the mouse
> pointer and framedropping may continue for a few (~15 tops) seconds
> after I stop moving that window around. Just moving the mplayer window
> around 'normally' doesnt cause any bad behavior (still with concurrent
> kernel and mozilla builds running).
>
> Basicly, for normal usage this kernel is acting *very* well here.

Great! Thanks for doing this testing. I've attached a patch with the updated 
figures and cc'ed lkml for others to test.

Con