| Summary: | [i915] Graphics Regression: Window dragging, opening very slow and laggy | ||
|---|---|---|---|
| Product: | DRI | Reporter: | aes368 |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED NOTOURBUG | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | intel-gfx-bugs |
| Version: | XOrg git | Keywords: | bisected, regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | SKL | i915 features: | |
| Attachments: | |||
|
Description
aes368
2016-11-16 20:04:22 UTC
Created attachment 128019 [details]
git bisect log
Created attachment 128020 [details]
dmesg after booting the bad kernel
Created attachment 128021 [details]
dmesg after booting the good kernel
Created attachment 128022 [details]
Screen capture showing slowness
Created attachment 128023 [details]
Screen capture showing expected performance for comparison
Created attachment 128024 [details]
lspci output
Created attachment 128025 [details]
ver_linux output from bad kernel
Created attachment 128026 [details]
ver_linux output from good kernel
Looking at "perf top" (or something like perf record -g -a sleep 60; perf report -G | head -5000) should give a clear indication as to whether the cause is CPU bound. Does not look CPU bound at all. In fact, i915 uses less time under the bad kernel. Could this be an Xorg or window manager issue? I have attached below the two perf data files. Created attachment 128029 [details]
perf data under bad kernel
Terminal window was dragged rapidly
Created attachment 128030 [details]
perf data under good kernel
Terminal window was dragged rapidly.
perf.data contains references to symbols that need to be resolved on your machine. Please run them through "perf report -G | head -5000" Created attachment 128035 [details]
perf report under bad kernel
Created attachment 128036 [details]
perf report under good kernel
Okay, attached above. Things look similar, except for (slightly) increased CPU usage on the good kernel. This is also evident using IceWM's CPU graph. Indeed, they are traces for relatively idle cpu handing off work to the gpu, and look consistent with each other. Neither are spending any time waiting for the gpu, which seems slightly odd, if it was a graphics slowdown we would start seeing throttling and lots of waiting around. Does boosting the priority of X make any difference? Are there unusual blocked (iowait?) tasks? About the only odd thing there is icewm consuming a lot of time reading thermals generating ACPI operations. Oh no! It's a window manager issue. Ordering of ACPI devices changed (due to the hashing change) and IceWM started polling the Wifi device, which apparently slows everything down. I noticed icewm was blocked on IO constantly (D in htop). Thanks for the help. |
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.