Mir is always in a busy wait, always using CPU
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Mir |
Fix Released
|
High
|
Alexandros Frantzis | |
| | The Ubuntu Power Consumption Project |
Undecided
|
Alexandros Frantzis | ||
Bug Description
Mir is always in a busy wait, always using CPU.
The rendering loop in mir is currently only throttled by vsync. So on my i7, at idle it still uses 2.7% CPU. If mir can't get the display however (like when it's started in VT screensaver mode or VT is switched) then mir is stuck at 100% CPU. Because it no longer has even vsync to slow it down.
A critical requirement for any non-game renderer is the ability to idle completely, and only redraw the screen when something changes. This is typically an event originating in an application.
Related branches
- PS Jenkins bot (community): Approve (continuous-integration) on 2013-03-28
- Daniel van Vugt: Abstain on 2013-03-28
- Kevin DuBois (community): Approve on 2013-03-27
- Alan Griffiths: Approve on 2013-03-27
-
Diff: 1186 lines (+456/-88)19 files modifiedexamples/render_surfaces.cpp (+3/-3)
include/server/mir/compositor/default_compositing_strategy.h (+3/-3)
include/server/mir/compositor/multi_threaded_compositor.h (+3/-0)
include/server/mir/compositor/renderables.h (+19/-9)
include/server/mir/compositor/rendering_operator.h (+1/-1)
include/server/mir/default_server_configuration.h (+2/-2)
include/server/mir/surfaces/surface.h (+3/-1)
include/server/mir/surfaces/surface_stack.h (+9/-3)
include/test/mir_test_doubles/stub_surface_builder.h (+1/-1)
src/server/compositor/default_compositing_strategy.cpp (+4/-4)
src/server/compositor/multi_threaded_compositor.cpp (+58/-5)
src/server/default_server_configuration.cpp (+4/-3)
src/server/surfaces/surface.cpp (+10/-2)
src/server/surfaces/surface_stack.cpp (+35/-11)
tests/unit-tests/compositor/test_default_compositing_strategy.cpp (+15/-12)
tests/unit-tests/compositor/test_multi_threaded_compositor.cpp (+152/-8)
tests/unit-tests/shell/test_surface.cpp (+1/-1)
tests/unit-tests/surfaces/test_surface.cpp (+77/-18)
tests/unit-tests/surfaces/test_surface_stack.cpp (+56/-1)
| Alan Griffiths (alan-griffiths) wrote : | #1 |
| Daniel van Vugt (vanvugt) wrote : | #2 |
From a unit-testing perspective you would start the server with no clients and verify it never calls render, or something like that.
| Daniel van Vugt (vanvugt) wrote : | #3 |
Also, even when the display is visible we should not assume to have vsync. Sometimes it will be a no-op if disabled in the driver settings, or if the screen is in sleep mode. And you'll get 100% CPU again.
| Daniel van Vugt (vanvugt) wrote : | #4 |
I saw alf was working on this in London. Is it finished?
| Changed in mir: | |
| assignee: | nobody → Alexandros Frantzis (afrantzis) |
| status: | New → In Progress |
| Alexandros Frantzis (afrantzis) wrote : | #5 |
This depends on display threading (but read below), which is blocked because we don't have Android support for it, since 1. I don't currently have hardware to develop/test, and 2. Kevin is on leave
Strictly speaking, we could have a fix for this in the current code, but since it's not critical that we solve this immediately, I'd rather not implement a temporary fix that is going to be thrown away when display threading arrives.
| Robert Ancell (robert-ancell) wrote : | #6 |
This is blocking VT switching (Bug #1102758)
| Changed in mir: | |
| importance: | Critical → High |
| information type: | Proprietary → Public |
| Changed in ubuntu-power-consumption: | |
| assignee: | nobody → Alexandros Frantzis (afrantzis) |
| status: | New → Confirmed |
| Changed in ubuntu-power-consumption: | |
| status: | Confirmed → In Progress |
| PS Jenkins bot (ps-jenkins) wrote : | #7 |
Fix committed into lp:mir at revision None, scheduled for release in mir, milestone Unknown
| Changed in mir: | |
| status: | In Progress → Fix Committed |
| Changed in mir: | |
| milestone: | none → 0.0.3 |
| Changed in mir: | |
| status: | Fix Committed → Fix Released |
| Changed in ubuntu-power-consumption: | |
| status: | In Progress → Fix Released |
This sounds like an important use case: How can we automate a test?