On Thu, 2003-12-04 at 23:38, Soeren Sonnenburg wrote: > On Thu, 2003-12-04 at 18:46, Michel Dänzer wrote: > > On Wed, 2003-12-03 at 07:30, Soeren Sonnenburg wrote: > > > > > > [...] I find that it might be some scheduling problem and not the > > > radeonfb: > > > > > > When I start find /home for the first time it scrolls slowly. When I do > > > it a second time it is still slow. But when I did it a third time it is > > > superb fast (only 45sec vs some minutes / approx the same in xterm)... > > > > > > When I do it now it seems to accelerate... it starts slow but becomes > > > much faster... > > > > I think I know what you mean now; scrolling or deleting lines in vim is > > very slow most of the time here now, but not always. Could indeed be a > > scheduler problem, or either gnome-terminal (you're using that as well, > > right?) or the X server doing something stupid which happened to have > > no. I am using multi-gnome-terminal. I strongly dislike gnome-terminal ( > a nice thing is that it has no probs with locales/ can use utf-8 > though). It also happens in xterm. Scrolling speed in xterm/mgt is > comparable... gt is much slower...
Out of curiosity, did you try gnome-terminal with an anti-aliased font? That would be expected to be slower. As it happens with several apps, my money is on the kernel scheduler. I wonder if it could be related to the fact that HZ is 1000 now? > What I find interesting is that the system (not cpu!) load is maxxed to > 100% all the time when scrolling in 2.6. but less than 50% in 2.4.... That's why it's slow I guess; CPU cycles are wasted for something. > Sounds like the some kernel driver eating up the time... which I thought > could be due to the new radeonfb driver.... It can't be because it's not involved in the X server drawing. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer
