Mir

Mir is always in a busy wait, always using CPU

Bug #1108725 reported by Daniel van Vugt
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
High
Alexandros Frantzis
The Ubuntu Power Consumption Project
Fix Released
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

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

This sounds like an important use case: How can we automate a test?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

From a unit-testing perspective you would start the server with no clients and verify it never calls render, or something like that.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I saw alf was working on this in London. Is it finished?

Changed in mir:
assignee: nobody → Alexandros Frantzis (afrantzis)
status: New → In Progress
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

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.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.