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

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

[Michael Tokarev]

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

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

[Andrew Morton]

(cc dri-devel)

On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev <mjt@tls.msk.ru> 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.
> 
> Thanks!
> 
> /mjt
> --
> 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/

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

[Mark Hounschell]

On 12/22/2010 05:00 AM, Andrew Morton wrote:
> (cc dri-devel)
>
> On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev <mjt@tls.msk.ru> 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.

I know its probably not proper to mention it, but when I run the ATI
proprietary
driver, that problem does go away. But for other reasons I can't use it.

Regards
Mark

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

[Michel Dänzer]

On Mit, 2010-12-22 at 05:55 -0500, Mark Hounschell wrote: 
> 
> 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.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

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

[Mark Hounschell]

On 12/23/2010 02:25 AM, Michel Dänzer wrote:
> On Mit, 2010-12-22 at 05:55 -0500, Mark Hounschell wrote: 
>>
>> 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.
> 
> 

Hum, but I do in fact see the same thing he sees on a VT. A dmesg
command from a VT  takes around 20 seconds to display. The same in a
konsole takes a fraction of a second.
So your probably right that my vi problem in a konsole is a different
issue. I do see the same thing as the OP does though. I just figured
they were probably related.

Changing fonts doesn't change anything though. I normally use the "Misc
Console" font FWIW.

Regards
Mark

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

[Pavel Machek]

Hi!

> 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...

Try "irqpoll"?

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

> 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?
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Michael Tokarev]

02.01.2011 12:00, Pavel Machek wrote:
> Hi!
> 
>> 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...
> 
> 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 ;)

> 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.

>> 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

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

[Michael Tokarev]

05.01.2011 01:50, Michael Tokarev wrote:
> 02.01.2011 12:00, Pavel Machek wrote:
>> Hi!
>>
>>> 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...
>>
>> 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 ;)

Two more data points.

irqpoll "helps" - it makes the scrolling "jumpy", it is
slow for a few first lines, next it speeds up but not to
full speed still, and the speed varies during one test
(while it scrolls, say, dmesg).

When performing syspend-to-disk cycle the speed restores
back to normal, regardless of irqpoll.

So it's definitely something to do with suspend-to-ram.

And there's more: the system does not perform suspend-to-ram
properly using "simple" way -- "echo mem > /sys/power/state".
This way, everything gets turned off (disks, monitor, usb
devices etc), but the power indicator stays on, and the system
does not react to anything - only hard reset works.  When using
pm-suspend it performs suspend correctly, and enters state when
the power indicator blinks, and power button returns the system
back to working state.  This is when run from "text" console,
but apparently this is another issue and is something new
(in 2.6.36), since I _know_ I used simple `echo mem' many times
before.

Thanks!

/mjt

>> 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.
> 
>>> 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