Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!

[Con Kolivas <kernel@kolivas.org>]

On Sun, 4 Jan 2004 22:13, Martin Schlemmer wrote:
> On Sun, 2004-01-04 at 10:49, Con Kolivas wrote:
> > > I added a fprintf(stderr, "%d\n", amount); to that code and indeed
> > > amount was *always* 1 no matter what I did (it even was 1 when the
> > > (dmesg/...) output came in fast). And jump scrolling would take place
> > > if amount > 59 in my case... can this still be not a schedulers issue ?
> > >
> > >
> > > Looking at that how can it not be a scheduling problem ....
> >
> > Scheduling problem, yes; of a sort.
> >
> > Solution by altering the scheduler, no.
> >
> > My guess is that turning the xterm graphic candy up or down will change
> > the balance. Trying to be both gui intensive and a console is where it's
> > happening. On some hardware you are falling on both sides of the fence
> > with 2.6 where previously you would be on one side.
>
> So its Ok for 'eye candy' to 'lag', but xmms should not skip?  Anyhow,
> its xterm that he have issues with, not gnome-terminal or such with
> transparency.  I smell something ...

Sigh... 

Xmms was a simple test case long forgotten but most still think all I did was 
make an xmms scheduler. Deleting one character from sched.c before all of my 
patches would make the scheduler ideal for xmms. Any braindead idiot can tune 
a scheduler for just one application. An application that changes it's 
behaviour dynamically well in the setting of a particular scheduler, though? 
Should a scheduler be tuned to suit a coding style or quirk? 

I should go back to lurking before people start calling me names. This thread 
has gone long enough for that. If I hadn't said anything it would have died 
out by now. Instead I'm drawing attention to my fundamentally flawed code.

Con