Red Hat Bugzilla – Bug 490839
Slow performance in some situations with the Rawhide kernel 2.6.29-0.25
Last modified: 2009-05-09 06:40:06 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):
Steps to Reproduce:
1. boot fedora rawhide kernel
2. run Xorg with UXA acceleration
3. start x11perf -f24itext16
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. ;(
Could you please add here reference to your upstream bug for this?
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...
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.
> 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:
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.
I'll extend this bugreport with few more things:
The problem is still present with 188.8.131.52-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.....
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-184.108.40.206-54.fc11 and xorg-x11-drv-intel-220.127.116.112-2.fc11 on my GM45. If anyone can still reproduce this kind of performance cliff with those versions or later, please reopen this bug.
I can confirm that kernel 18.104.22.168-54.fc11 fixes this performance regression - very nice - thanks
This kernel also seem to survive my glxgears reported problem:
So very good work - I hope these kernel patches quickly reach the vanilla kernel.
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.
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
Yeah, I will continue over on bug 494753
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.