VERY slow scrolling on radeon graphics card: debugging a timing issue?

Hello.

A weird problem here, and I'm looking for help in an attempt to solve it.

Ever since KMS went into kernel and I tried turning it on, the scrolling speed on the resulting "text" console (with kms it works in one of graphics modes hence "text" in quotes) become really _awful_.

For example, running `dmesg' (which has ~2000 lines) on the console takes about 2.5 _minutes_ (!) to complete, -- which means the speed is about 10 lines per second. On an old notebook I have, with some also nvidia card, the same operation completes in about 0.8 sec.

The lines goes up in a slow motion, I can watch every new line appearing and scrolling.

It was this way for a long time, and I almost gave up -- in X everything works ok, and in order to speed up booting again I just added "quiet" option to the kernel command line, to avoid scrolling of kernel messages.

But yesterday I noticed something else entirely, which make me hope the problem actually _can_ be solved.

The thing is: that same scrolling becomes much faster when I "do something" else while it scrolls up. First I noticed this when I wanted to switch to another vt while it were scrolling -- I held down Ctrl key on my keyboard, and out of the sudden the scroll speed up dramatically.

It turned out I can speed the thing to about 10 times by generating some load: hit and hold a key on the keyboard (generates interrupts?), run kernel compile in the background (generates disk interrupts?), move mouse...

While doing "something", the same scrolling completes in about 8 seconds instead of 2m30s. Dramatic improvement.

Now, when I hold a key or move mouse, the scrolling is "jumpy" - sometimes it slows down back to original "slow" form for a bit, and sometimes it jumps a few lines in one go.

I tried to disable cpufreq (selecting "performance" governor) - this changes exactly nothing.

Next someone suggested the "perf" tool. And this one is even more interesting: while perf top' is running (on another console or X), the scrolling is.. fast again, as if I were moving my mouse! Once I stop perf top', it becomes slow again. So the bug disappears while you watch it.

And there I'm stuck again. I asked in #radeon, but there, Alex Deucher told me that he has no clue and that the behavour is weird (it is weird indeed).

Any hints on where to go from there are apprecated.

The hardware is an AMD780g-based motherboard with and Athlon CPU, I've seen the same behavour from many other similar boards. Kernels - all up to the current 2.6.36.2, sine the old days when kms for radeon first appeared in staging.

I know kms/fbcon scrolling is slow on radeon because it uses completely unoptimized bitblt routines (even when the hw is pretty much capable of doing all that stuff internally). But what I see here is something different - the 8 sec to scroll 2000 lines is the result from the un-optimal bitblt, not the 2m30s.

Thanks!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

(cc dri-devel)

Quoted 78 lines · On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev <[email protected]> wrote:

Hello.

A weird problem here, and I'm looking for help in an attempt to solve it.

Ever since KMS went into kernel and I tried turning it on, the scrolling speed on the resulting "text" console (with kms it works in one of graphics modes hence "text" in quotes) become really _awful_.

For example, running `dmesg' (which has ~2000 lines) on the console takes about 2.5 _minutes_ (!) to complete, -- which means the speed is about 10 lines per second. On an old notebook I have, with some also nvidia card, the same operation completes in about 0.8 sec.

The lines goes up in a slow motion, I can watch every new line appearing and scrolling.

It was this way for a long time, and I almost gave up -- in X everything works ok, and in order to speed up booting again I just added "quiet" option to the kernel command line, to avoid scrolling of kernel messages.

But yesterday I noticed something else entirely, which make me hope the problem actually _can_ be solved.

The thing is: that same scrolling becomes much faster when I "do something" else while it scrolls up. First I noticed this when I wanted to switch to another vt while it were scrolling -- I held down Ctrl key on my keyboard, and out of the sudden the scroll speed up dramatically.

It turned out I can speed the thing to about 10 times by generating some load: hit and hold a key on the keyboard (generates interrupts?), run kernel compile in the background (generates disk interrupts?), move mouse...

While doing "something", the same scrolling completes in about 8 seconds instead of 2m30s. Dramatic improvement.

Now, when I hold a key or move mouse, the scrolling is "jumpy" - sometimes it slows down back to original "slow" form for a bit, and sometimes it jumps a few lines in one go.

I tried to disable cpufreq (selecting "performance" governor) - this changes exactly nothing.

Next someone suggested the "perf" tool. And this one is even more interesting: while perf top' is running (on another console or X), the scrolling is.. fast again, as if I were moving my mouse! Once I stop perf top', it becomes slow again. So the bug disappears while you watch it.

And there I'm stuck again. I asked in #radeon, but there, Alex Deucher told me that he has no clue and that the behavour is weird (it is weird indeed).

Any hints on where to go from there are apprecated.

The hardware is an AMD780g-based motherboard with and Athlon CPU, I've seen the same behavour from many other similar boards. Kernels - all up to the current 2.6.36.2, sine the old days when kms for radeon first appeared in staging.

I know kms/fbcon scrolling is slow on radeon because it uses completely unoptimized bitblt routines (even when the hw is pretty much capable of doing all that stuff internally). But what I see here is something different - the 8 sec to scroll 2000 lines is the result from the un-optimal bitblt, not the 2m30s.

I also see this very problem on several machines I have with radeon video. For me the worst part is using vi in a konsole. Moving the cursor around is so slow that I just can't use these machines directly and have to ssh into them from another machine just to work on them.

Quoted 5 lines · Mark Hounschell

I also see this very problem on several machines I have with radeon video. For me the worst part is using vi in a konsole. Moving the cursor around is so slow that I just can't use these machines directly and have to ssh into them from another machine just to work on them.

That's not the same problem as the one described by Michael, which is about the console on virtual terminals different from X.

For your problem, try choosing a different font (a fontconfig one instead of a legacy X one) in konsole.

The thing is: that same scrolling becomes much faster when I "do something" else while it scrolls up. First I noticed this when I wanted to switch to another vt while it were scrolling -- I held down Ctrl key on my keyboard, and out of the sudden the scroll speed up dramatically.

It turned out I can speed the thing to about 10 times by generating some load: hit and hold a key on the keyboard (generates interrupts?), run kernel compile in the background (generates disk interrupts?), move mouse...

Any hints on where to go from there are apprecated.

The hardware is an AMD780g-based motherboard with and Athlon CPU, I've seen the same behavour from many other similar boards. Kernels - all up to the current 2.6.36.2, sine the old days when kms for radeon first appeared in staging.

Hi!

Quoted 7 lines

The thing is: that same scrolling becomes much faster when I "do something" else while it scrolls up. First I noticed this when I wanted to switch to another vt while it were scrolling -- I held down Ctrl key on my keyboard, and out of the sudden the scroll speed up dramatically.

Quoted 5 lines

It turned out I can speed the thing to about 10 times by generating some load: hit and hold a key on the keyboard (generates interrupts?), run kernel compile in the background (generates disk interrupts?), move mouse...

Try "irqpoll"?

Will cpu load speed it up, too? (Like yes > /dev/null)?

Quoted 7 lines

Any hints on where to go from there are apprecated.

The hardware is an AMD780g-based motherboard with and Athlon CPU, I've seen the same behavour from many other similar boards. Kernels - all up to the current 2.6.36.2, sine the old days when kms for radeon first appeared in staging.

Watch /proc/interrupts to see if radeon uses them and if they appear to work?

Quoted 15 lines · Pavel Machek

Hi!

Quoted 12 lines

The thing is: that same scrolling becomes much faster when I "do something" else while it scrolls up. First I noticed this when I wanted to switch to another vt while it were scrolling -- I held down Ctrl key on my keyboard, and out of the sudden the scroll speed up dramatically.

It turned out I can speed the thing to about 10 times by generating some load: hit and hold a key on the keyboard (generates interrupts?), run kernel compile in the background (generates disk interrupts?), move mouse...

Quoted 1 line

Try "irqpoll"?

It turned out to be a bit less easy than I thought.

The thing is, it appears the issue is not triggered on fresh boot - scrolling is reasonable fast there. But slowness returns back after suspend-to-RAM cycle (not suspend-to-disk). I'm still trying ;)

Quoted 1 line

Will cpu load speed it up, too? (Like yes > /dev/null)?

Yes, CPU load fixes the issue immediately. But switching from ondemand to performance CPU governor does not fix it.

Quoted 10 lines

Quoted 7 lines

Any hints on where to go from there are apprecated.

The hardware is an AMD780g-based motherboard with and Athlon CPU, I've seen the same behavour from many other similar boards. Kernels - all up to the current 2.6.36.2, sine the old days when kms for radeon first appeared in staging.

Watch /proc/interrupts to see if radeon uses them and if they appear to work?

I don't see any change in radeon interrupt numbers during the scrolling, so it's difficult to say. The IRQ is shared between several devices:

$ grep radeon /proc/interrupts
  18:  510439  370  IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, radeon

The counter changes but very slowly (and not during the scroll test when I don't touch anything), I see on correlation between it any my actions.

Thanks!

/mjt