Bug 1021511
Summary: | Lightbox implementation kills performance on LiveCDs (XFCE completely unusable in VM) | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||||||
Component: | anaconda | Assignee: | David Shea <dshea> | ||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | 20 | CC: | amulhern, anaconda-maint-list, awilliam, bitlord0xff, bnocera, dshea, g.kaviyarasu, jonathan, kevin, mkolman, mruckman, otaylor, piruthiviraj, robatino, sbueno, vanmeeuwen+fedora | ||||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||||
Target Release: | --- | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | AcceptedFreezeException | ||||||||||||
Fixed In Version: | anaconda-20.25.4-1 | Doc Type: | Bug Fix | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2013-11-06 18:08:37 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 980655, 980656 | ||||||||||||
Attachments: |
|
Description
Kamil Páral
2013-10-21 12:41:21 UTC
Created attachment 814581 [details]
DVD in a VM (2 cpus)
Everything is super-fast. No compositing? Different implementation of lightboxes?
Created attachment 814582 [details]
GNOME in a VM (2 cpus)
Slow during reclaim, otherwise OK.
Created attachment 814583 [details]
KDE in a VM (2 cpus)
CPU utilization is 100%, slow during reclaim, otherwise OK.
Created attachment 814584 [details]
XFCE in a VM (2 cpus)
Unusable. The end of the video is cut short, I stopped the recording. But if I had waited 20 more seconds, the reclaim dialog would have appeared.
Note: With only 1 CPU assigned, you can't even display the "accept your fate" dialog in 3 minutes of waiting.
I think this is a strong candidate for Final blocker. XFCE is not a release blocking desktop, but it completely kills it and also very noticeably affects GNOME and KDE. I guess this is a duplicate or related to bug 1019501 ? Kamil, you have described it beautifully in this bug report. This is exactly what happens on my laptop with ivybridge setup Lenovo Y580. This is happenening since TC for alpha and continues to exist until TC5 beta for me. +1 for Final blocker. Discussed this in 2013-10-21 Blocker Review Meeting [1]. Accepted as a freeze exception issue, as it's effectively a showstopper for installation with non-blocker desktop live images. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-21/ This has nothing to do with the lightbox implementation *** This bug has been marked as a duplicate of bug 1019501 *** When Vratislav Podzimek edited anaconda source code and commented out lightbox creation method, everything was snappy even with XFCE. So it is definitely related to lightboxes. I'm not saying it's an anaconda fault, it might be a gtk bug or something. But it is not an XFCE-specific thing (please see the attached videos and read the description). Because you consider bug 1019501 to be XFCE-specific (which might or might not be true), I'm de-duplicating this report again. So, I've figured out that the anaconda_lb_configure_event is called again and again causing high CPU usage. However, it might be an issue in the xfwm4 because both anaconda and xfwm4 take ~30 % CPU, the X server another 50 %. David, could you please have a look at this? I think we need to test if the same happens in the other window managers as well (probably not at least in metacity used for DVD installations) and reassing this bug if it really is xfwm4 specific. That's weird, I'm not seeing the configure-event handler being called at all. However, I do see that xfce is trying to treat the lightbox as a separate window (since we're creating it as a top level, I guess), and that could be causing problems. It might be that xfce makes the lightbox more likely to be moved/movable than GNOME does, and since we call gdk_window_restack within the configure-event handler I can see that possibly causing a configure-event loop. It's pretty crummy performance-wise even without a configure-event loop, though. This is a wild guess, but could this be caused by this? http://www.hadess.net/2013/10/reducing-wake-ups-2013-edition.html https://bugzilla.gnome.org/show_bug.cgi?id=710666 IIUIC, it's a GTK regression that causes window updates even when nothing has changed. Bastien, Owen, can you provide some advice here? *** Bug 1019501 has been marked as a duplicate of this bug. *** Never mind, it's the configure-event on the lightbox itself that's getting stuck in a loop; I was looking at the configure-event on the parent window. Patch posted. Try http://dshea.fedorapeople.org/updates-1021511-x86_64.img as an updates image. Just replaced that updates.img with one that includes a patch from bcl that fixes a crash in BaseWindow that fixing the lightbox ceases to hide. The updates.img from comment 16 was causing troubles, a fixed version is at: http://dshea.fedorapeople.org/updates-1021511-2-x86_64.img I tested XFCE with it and lightboxes are super-quick again, they don't hog CPU when displayed. I tested KDE with the update, lightboxes no longer hog the CPU. GNOME is also fine, but it was fine even before. The resize dialog is still very slow when compared to DVD. Now when lightboxes are fixed, one can easily see that the performance is similar on all Lives regardless of environment, just DVD is super-fast. It might be still related to lightboxes, or it might be a completely different issue. anaconda-20.25.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.4-1.fc20 20.25.4-1 went stable as a part of FEDORA-2013-20033 and the fix was verified, so this can be closed. |