Bug 490839 - Slow performance in some situations with the Rawhide kernel 2.6.29-0.25
Slow performance in some situations with the Rawhide kernel 2.6.29-0.25
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-18 05:47 EDT by Zdenek Kabelac
Modified: 2009-05-09 06:40 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-17 11:42:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zdenek Kabelac 2009-03-18 05:47:11 EDT
Description of problem:

Ok I'm not really sure where should I place this bug - whether in kernel or intel driver or drm library - so let's try here - feel free to select better component.

I'm seeing very very very very slow performance in some situations with current Rawhide kernel (2.6.29-0.258.rc8.git2.fc11.x86_64). It's not the first kernel with this problem - but rather the first I've tried to find out the test case.

I think it's nicely shown with this command:  "x11perf -f24itext16"

On the non GL accelerated Xorg (i.e. no Compiz) it will give me just 5400/sec.
When I enable Compiz I get:  200000/sec

So in some cases for some applications I could see how they are 'drawing' letters - nice for catching bug in Expose handling - but otherwise not really usable.

Using UXA acceleration.

When I run sysprof to see why it's so slow - it looks like 95% is spend in the routine drm_clflush_pages() - though I'm not sure how reliable these results really are - I suspect, sysprof is not always correct....

Also another interesting fact is - that while it's very slow without Compiz, but when I enable Compiz I'm getting lower numbers with my vanilla kernel (also with lots of debug option enabled) - so there is surely some kind of magic inside the Rawhide kernel, which makes it faster in this case.

Version-Release number of selected component (if applicable):
kernel-2.6.29-0.258.rc8.git2.fc11.x86_64
xorg-x11-drv-intel-2.6.0-14.fc11.x86_64
xorg-x11-server-Xorg-1.6.0-13.fc11.x86_64
libdrm-2.4.5-0.fc11.x86_64


How reproducible:
always

Steps to Reproduce:
1. boot fedora rawhide kernel
2. run Xorg with UXA acceleration 
3. start x11perf -f24itext16
  
Actual results:


Expected results:


Additional info:
Comment 1 Kevin Fenzi 2009-03-18 12:21:58 EDT
I was seeing something very like this here as well... in my case it was a tigervnc session to a bgr233 server. Without Composite enabled it was unusable and 100% cpu. Enable Composite and it's much much faster. ;(
Comment 2 Matěj Cepl 2009-03-31 12:29:23 EDT
Could you please add here reference to your upstream bug for this?
Comment 3 Zdenek Kabelac 2009-04-01 03:56:49 EDT
I think it's the Fedora's 'feature' - this problem doesn't appear with upstream vanilla Linux kernel - I guess it's the result of using drm-next branch - unfortunately there is non-trivial amount of patches included within rawhides' kernel - so it's really hard to guess which patch introduces this problem...
Comment 4 Tomáš Bžatek 2009-04-01 06:56:30 EDT
I'm having kind of similar issue - vncviewer, lines test in gtkperf, image scrolling in EOG and GThumb are unbearably slow, like not accelerated. Reverting to vanilla 2.6.29 didn't help though.

That was with Intel KMS, UXA, DRI2. So I'm back to UMS and EXA/DRI1, which works fine.
Comment 5 Clemens Eisserer 2009-04-01 13:28:47 EDT
> I'm having kind of similar issue - vncviewer, lines test in gtkperf, image
> scrolling in EOG and GThumb are unbearably slow, like not accelerated.
It has never been accalerated, however UXA has terrible fallback handling:
https://bugs.freedesktop.org/show_bug.cgi?id=20698

That means if UXA is forced out of accaleration somehow (e.g. lines, core fonts, ...) performance is horrible. This also affects GTK+-1.2/Motif apps as well.
Comment 6 Zdenek Kabelac 2009-04-03 09:42:54 EDT
I'll extend this bugreport with few more things:

The problem is still present with 2.6.29.1-37.rc1.fc11.x86_64
With kernel option 'nomodesetting' it seems to be working much faster with my test case.

So the problem is related with KMS (which I'm not using with vanilla kernel)

If I'm running without modesetting - and I try to manipulate brightness of my laptop, the speed of OpenGL drastically drops down and never gets back.
And brightness look pretty weird anyway.

I'm getting curious how this is connected together.....
Comment 7 Adam Jackson 2009-04-09 14:04:54 EDT
This was mostly due to how software fallbacks were handled in UXA with KMS.  We'd map the entire front-buffer cacheable, do some (very little) drawing, and then unmap it.  To guarantee consistency we'd clflush the whole thing on unmap.  8M cache flushes are not especially fast.

This should be resolved in newer kernels, as we use uncached GTT maps for software fallbacks now.  x11perf -ftext gets reasonable-looking numbers with kernel-2.6.29.1-54.fc11 and xorg-x11-drv-intel-2.6.99.902-2.fc11 on my GM45.  If anyone can still reproduce this kind of performance cliff with those versions or later, please reopen this bug.
Comment 8 Zdenek Kabelac 2009-04-10 05:30:22 EDT
I can confirm that kernel 2.6.29.1-54.fc11 fixes this performance regression - very nice - thanks 

This kernel also seem to survive my glxgears reported problem:
https://bugs.freedesktop.org/show_bug.cgi?id=21083

So very good work - I hope these kernel patches quickly reach the vanilla kernel.
Comment 9 Kevin Fenzi 2009-04-10 13:01:48 EDT
Well, the behavior here is different now, but still not ideal. ;) 

Anytime I open a virt-viewer, the entire machine freezes for about 20 seconds or so, then it all comes back and works ok. 

Dmesg has tons of: 

X:2959 freeing invalid memtype d8db9000-d8dba000
X:2959 freeing invalid memtype d8dbb000-d8dbc000
X:2959 freeing invalid memtype d8dbd000-d8dbe000

Nothing that looks out of the ordinary in Xorg.0.log. 

I do have COMPOSITE enabled via the xfwm4 window manager. 

Happy to provide more info or test.
Comment 10 Adam Williamson 2009-04-16 18:46:47 EDT
I'm thinking you should probably open a new report, Kevin, just to keep things clean - it doesn't sound like it was quite the same problem in the first place.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 11 Kevin Fenzi 2009-04-17 11:42:17 EDT
Yeah, I will continue over on bug 494753
Comment 12 Clemens Eisserer 2009-05-09 06:40:06 EDT
Ajax: Could it be the change to the caching mode slows down trapezoid heavy applications?

I already reported a bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=21376

I see awful lot of cycles spent in rasterizeEdges, and e.g. for the QGears2 benchmark I get about 1/10 of the framerate compared to Fedora8+EXA.

Note You need to log in before you can comment on or make changes to this bug.