Bug 175942 - [GTK][Wayland] Opening FedoraProject's pastebin chews CPU
Summary: [GTK][Wayland] Opening FedoraProject's pastebin chews CPU
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2017-08-24 10:21 PDT by Bastien Nocera
Modified: 2018-02-23 13:12 PST (History)
7 users (show)

See Also:

WIP (5.08 KB, patch)
2017-08-31 08:54 PDT, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Patch (9.96 KB, patch)
2017-09-01 05:23 PDT, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Patch (9.95 KB, patch)
2017-09-01 05:28 PDT, Carlos Garcia Campos
no flags Details | Formatted Diff | Diff
Patch (10.00 KB, patch)
2017-09-01 09:14 PDT, Carlos Garcia Campos
zan: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bastien Nocera 2017-08-24 10:21:42 PDT

Opening "https://paste.fedoraproject.org/paste/KPHOZTH~E8zjRJtXkOQEcQ" (for example) in MiniBrowse or epiphany eats through CPU, with the WebKitProcess taking 2/3 of a core, and the browser binary taking the other 1/3.
Comment 1 Carlos Garcia Campos 2017-08-31 06:35:40 PDT
I can reproduce this, but only under wayland (doesn't happen using GDK_BACKEND=x11) and with AC enabled.
Comment 2 Carlos Garcia Campos 2017-08-31 06:52:54 PDT
It seems we are rendering at a crazy frame rate, I guess because of the display monitor thing.
Comment 3 Carlos Garcia Campos 2017-08-31 07:04:13 PDT
This regressed when we introduced the display refresh monitor. The monitor schedules updates immediately, because we removed the option to not do frame sync in X11 to let swapBuffers do the throttling. That doesn't happen in Wayland, so I guess we need to properly implement the frame request callbacks in the nested compositor.
Comment 4 Carlos Garcia Campos 2017-08-31 08:54:42 PDT
Created attachment 319463 [details]

This is a WIP patch, it fixes the issue, but also introduces locks. Now I remember this was the other reason why we didn't implement the frame callbacks this way. Problem is that mesa calls wl_display_dispatch_queue in a loop, but the main thread is blocking trying to make a sync threaded compositing task (for repaint). See the bt:

Thread 13 (Thread 0x7f74077fe700 (LWP 20452)):
#0  0x00007f747505966d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f7475bb6769 in ?? () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#2  0x00007f7475bb7dac in wl_display_dispatch_queue () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#3  0x00007f747d619d0b in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
#4  0x00007f747d61a14c in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
#5  0x00007f747d61a224 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
#6  0x00007f7417ab2848 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#7  0x00007f7417ab2ba1 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#8  0x00007f7417a9dc84 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#9  0x00007f7483338437 in WebCore::GraphicsContext3D::clear(unsigned int) () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#10 0x00007f748265cc0b in WebKit::CoordinatedGraphicsScene::paintToCurrentGLContext(WebCore::TransformationMatrix const&, float, WebCore::FloatRect const&, WebCore::Color const&, bool, WebCore::FloatPoint const&, unsigned int) () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#11 0x00007f7482666ab1 in WebKit::ThreadedCompositor::renderLayerTree() () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37

Thread 1 (Thread 0x7f7484c8ea80 (LWP 20432)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f747f2240eb in WTF::ThreadCondition::timedWait(WTF::Mutex&, double) () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18
#2  0x00007f747f1eb9e3 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) ()
   from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18
#3  0x00007f7482664004 in WebKit::CompositingRunLoop::performTaskSync(WTF::Function<void ()>&&) () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#4  0x00007f7482666600 in WebKit::ThreadedCompositor::forceRepaint() () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#5  0x00007f74827b432f in WebKit::AcceleratedDrawingArea::layerHostDidFlushLayers() () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37
#6  0x00007f74827bc14e in WebKit::CoordinatedLayerTreeHost::layerFlushTimerFired() () from /home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37

Any idea?
Comment 5 Carlos Garcia Campos 2017-09-01 05:23:09 PDT
Created attachment 319593 [details]
Comment 6 Build Bot 2017-09-01 05:25:28 PDT
Attachment 319593 [details] did not pass style-queue:

ERROR: Source/WebKit/UIProcess/gtk/WaylandCompositor.h:90:  The parameter name "webPage" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 5 files

If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 7 Carlos Garcia Campos 2017-09-01 05:28:36 PDT
Created attachment 319594 [details]

Fix coding style
Comment 8 Carlos Garcia Campos 2017-09-01 09:14:41 PDT
Created attachment 319600 [details]

Fixed changelog entry, for some reaosn the first line was missing, shrug.
Comment 9 Carlos Garcia Campos 2017-09-02 00:05:58 PDT
Committed r221514: <http://trac.webkit.org/changeset/221514>
Comment 10 Michael Catanzaro 2018-02-23 13:12:23 PST
Regression: bug #183091.