Created attachment 15661 [details] My current xorg.conf. Noticing a steady and significant decline in X performance when rendering large changes to what's on screen. (eg. switching workspaces or Firefox tabs) When X is first started everything behaves nicely with performance similar to what I'm used to with the nvidia driver. However within an hour or two significant lag starts to develop when navigating and CPU usage seems to be spiking quite hard while the rendering is taking place. ('top' indicates the process is X) Window borders are visible somewhat quickly but the contents of those windows seems to be what takes the most time to appear. Replicated using Openbox window manager and about 6 workspaces, although only 3 in use with approximately 4 Gnome terminals open and one Firefox instance. OS is Fedora 9 beta. Will attach xorg.conf and X log below. Please let me know if there is any additional info I can provide or particular things to test to help isolate the issue I'm seeing.
Created attachment 15664 [details] Xorg.0.log
Some further testing: • Workspace switching noticeably slower after just 20 minutes. • Switched to Metacity after starting to notice the lag, appears to make no difference. • Actual process listed in top when CPU goes up during a laggy workspace switch is Xorg. • System memory usage fine, below 50%. • No swap in use. • Restarting X makes things go back to normal.
My guess is ExaMarkUsed() is to blame, a run of oprofile would reveal this. This is known problem, not specific to nouveau, fixed in xserver git (as of a few days ago). Otherwise i wouldn't know.
Another possibility is EXA offscreen memory fragmentation. Does VT switching to console and back improve performance temporarily?
Tried VT switching but I can't notice any difference when switching back. Have been running without restart all morning and definitely seeing a progressively worse delay switching desktops, up to around 3s to switch currently. Was becoming worried that some of what I'm seeing may just be the difference in performance from the driver I'm used to. Certain operations are brutally chuggy, scrolling in FF3+Gmail, pressing Esc on an empty command buffer in vim-gnome, or rendering any app running on the network via ssh forwarding. I was concerned I was confusing these with a performance bug but I'm definitely seeing it get worse and worse as the day wears on. Not sure if it will peak yet.
Correction, now that the lag is getting really terrible, re-tried VT switching and this *definitely* made a difference. After switching back the desktop switching isn't blazing but it's a far cry better, renders within a second whereas it was taking almost 4-5 before.
Created attachment 16254 [details] kernel and module's log I also experienced slowdown in performance. The session has been running for more than a day with a remote ssh login and glxgears and xscreensaver demo's run twice with gallium drive. I've tried switching VTs but that results in screen corruption.
Created attachment 16255 [details] Xorg's log
Created attachment 16256 [details] [review] Test patch (In reply to comment #7) > [...] glxgears and xscreensaver demo's run twice with gallium drive. Do you mean GL performance degrades? That's probably not directly related to EXA. Does this patch help for the problem reported originally? It implements a simple defragmentation algorithm. Whether it helps or not, please provide the output of grep Defrag /var/log/Xorg.0.log after running for a while with the patch applied. I'm still looking for better heuristics for when to do the defragmentation. Note that there have been some recent EXA changes only available on the xserver master branch so far which could help for this as well (or should at least improve text performance a lot).
Does the current git Nouveau driver still exhibit degrading performance over time?
Sorry I cannot test Nouveau behavior today, upgraded hardware no longer Nvidia.
Okay, thanks. Closing as fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.