Created attachment 61333 [details] Full perf report I'm not quite sure where exactly the problem is hidden - so take this BZ report as first approximation to begin with. The problem which I observe on my system is - when the number of opened tabs in firefox browser grows above some level - the system becomes quite slow in GUI responses (sluggish). I'm running kernel vanilla 3.3 with certain level of debug code enabled - so it's not ultimately fast - but it's fast enough on my 2.2GHz. xorg-x11-server-Xorg-1.12.0-4.fc18.x86_64 xorg-x11-drv-intel-2.18.0-2.fc18.x86_64 Here is top-ten of perf record when the system is visibly slower: 6,69% ff libxul.so [.] 0xd5179 4,10% X [kernel.kallsyms] [k] __lock_acquire 4,09% X [kernel.kallsyms] [k] lock_is_held 3,38% X [i915] [k] i915_gem_execbuffer_relocate_entry 2,83% X libdrm_intel.so.1.0.0 [.] 0x6760 2,63% tb libxul.so [.] 0x12009fc 1,76% X [kernel.kallsyms] [k] debug_smp_processor_id 1,75% X [kernel.kallsyms] [k] lock_release 1,63% X [kernel.kallsyms] [k] native_sched_clock 1,54% X [kernel.kallsyms] [k] add_preempt_count 1,49% X [kernel.kallsyms] [k] sched_clock_local 1,42% X [kernel.kallsyms] [k] lock_acquire 1,32% X [kernel.kallsyms] [k] trace_hardirqs_off_caller 1,27% X [kernel.kallsyms] [k] copy_user_generic_string 1,24% X [kernel.kallsyms] [k] sub_preempt_count 1,09% X [i915] [k] i915_gem_do_execbuffer.isra.8 1,09% X [drm] [k] drm_clflush_pages So my question is - is the i915 driver using some linear list, and when number of elements goes higher, list search becomes ineffective? # cat i915_gem_objects 1482 objects, 120209408 bytes 570 [551] objects, 78430208 [49680384] bytes in gtt 18 [17] active objects, 8556544 [8548352] bytes 3 [3] pinned objects, 7192576 [7192576] bytes 549 [531] inactive objects, 62681088 [33939456] bytes 0 [0] freed objects, 0 [0] bytes 4 pinned mappable objects, 15581184 bytes 412 fault mappable objects, 10981376 bytes 536866816 [268435456] gtt total
Created attachment 61335 [details] Content of some files from /sys/kernel/debug/dri/0 Unsure if this has any use - but might be handy...
Can you attach your Xorg.0.log? In particular I want to know the driver version and whether you are using UXA or SNA. Firefox has a habit of continuing to render in the background tabs, so it might just be the genuine accumulation of work that is slowing things down; certainly the slow profile would seem just to indicate time is being spent context switching and executing batches (though with large numbers of entries which is why I'm hoping this is UXA).
Created attachment 61337 [details] Xorg log
Ok, you probably really, really want to retest with SNA. :)
So I've recompiled git head for drm & xf86 intel driver with --enable-sna - and I've to admit, the desktop is much more fluent at first sight. While I still could imagine much more instant 'mc' window refresh in gnome-terminal, it's now much better 'desktop experience'. I'll keep an eye whether I'll notice any acceleration artifact, like I've always used to get when I've tried SNA in past. So far it looks good enough. Also next item is probably to open BZ against Rawhide package to enable build of SNA for intel drv package (since the package seems to only contain UXA driver).
Also, now is the time to set your aspirations for SNA :) If there is any scenario you suspect is being bottlenecked due to the driver, just let me know. gnome-terminal is a little tricky, since the amount of code between mc and the display is mind-boggling ;-)
If do encounter a scenario which you feel could be improved, please do let me know. (Preferably some sort of scriptable benchmark ;-)
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.