Messages in this thread | | | From | Con Kolivas <> | Subject | Re: xterm scrolling speed - scheduling weirdness in 2.6 ?! | Date | Sun, 4 Jan 2004 19:49:27 +1100 |
| |
On Sun, 4 Jan 2004 19:09, Soeren Sonnenburg wrote: > On Sun, 2004-01-04 at 02:42, Con Kolivas wrote: > > Not quite. The scheduler retains high priority for X for longer so it's > > no new dynamic adjustment of any sort, just better cpu usage by X (which > > is why it's smoother now at nice 0 than previously). > > But why is i.e. running the command a second or third time much faster > compared with the first run ? Does X get less priority then ?
Yes. X retains high priority for longer than previous scheduler designs.
> > > If either the scheduler or xterm was a bit smarter or > > > used different thresholds, the problem would go away. It would also > > > explain why there are people who cannot reproduce it. Perhaps a > > > somewhat faster or slower system makes the problem go away. Honnestly, > > > it's the first time that I notice that my xterms are jump-scrolling, it > > > was so much fluid anyway. > > > > Very thorough but not a scheduler problem as far as I'm concerned. Can > > you not disable smooth scrolling and force jump scrolling? > > I think it is a schedulers problem as it works if you run the program in > question often enough (dmesg/find/whatever). Suddenly it comes back to > full scrolling speed. > > Judging from the xfree4.3 xterm sources this is the function that gets > called when there is something to scroll. And it looks perfectly ok to > *me* as it scrolls amount lines at once. So the output of (dmesg/...) > seems to be received slower or xterm updates more often than in 2.4. > leading to fewer lines to scroll (== amount). It cannot be xterm > updating more often as it would a) be faster than and b) amount would be
It's a timing issue. X gets more priority for longer than previously so X gets to do more work.
> >>> 1 on later on which would lead to high scrolling speed again. > > So IMHO it must be the output of the program that is coming in slowly. > > 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.
Con
- 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/
| |