If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

High CPU load when showing notification about incoming SMS

RESOLVED WONTFIX

Status

Firefox OS
Gaia::SMS
RESOLVED WONTFIX
3 years ago
7 months ago

People

(Reporter: mac, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:-, tracking-b2g:backlog, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)

Details

(Whiteboard: [hamachi])

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

1. Lock the device - screen is off.
2. Send SMS to the device.


Actual results:

About 57% CPU load when screen turns on and notification appears on the top of the screen.


Expected results:

It can't consume so much of CPU power just to show static notification about incoming SMS message.

Tested on:

Alcatel One Touch Fire production (got from T-mobile Poland)
B2G version: 2.2.0.0-prerelease master
Platform version: 36.0a1
Build Identifier: 20141128194540
Git commit info: 2014-11-28 13:27:14 7d3f9852
(Reporter)

Updated

3 years ago
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Whiteboard: [hamachi]
(Reporter)

Comment 1

3 years ago
Profile taken during the scenario execution:

http://people.mozilla.org/~bgirard/cleopatra/#report=2de21c91db0969d485e0e1b4280f4169a38b6478
Could you clarify that "lock" the device means with LockScreen (it shows after pressing power button again), or without it (just black out)? If both cases the performance downgrade happens, this is a bug not of LockScreen component. If you only test with one case you may try the other one.
And from the profile I see that it spends 29% time on "DataStoreDB.prototype.txn", and 25.2% on "AsyncConnectionHelper". None of these looks related to LockScreen.
(Reporter)

Comment 4

3 years ago
I mean the state when user pressed LID button and screen has turned off.
(In reply to mac from comment #4)
> I mean the state when user pressed LID button and screen has turned off.

Yeah, not a lockscreen issue.


Baku, looking at the profile I think this has something to do with the Datastore API and possibly it's underlying use of IndexedDB. Can you take a look at the profile and help us confirm?
Flags: needinfo?(amarchesini)
How many items do you ask in that DataStore::get() ? Just 1 ore more than 1?
Flags: needinfo?(amarchesini)
Flags: needinfo?(mhenretty)
It looks like the DataStore transaction is coming from editing the places database in the system app. I spoke with :kgrandon on IRC about it, and he says he can help take a look.
Component: Gaia::System::Lockscreen → Gaia::SMS
Flags: needinfo?(mhenretty) → needinfo?(kgrandon)
Don't know why you changed the Component :) Maybe you wanted Gaia::System?
Component: Gaia::SMS → Gaia::System
Let's consider blocking for this performance (and likely battery !) improvement.
blocking-b2g: --- → 2.2?
I was unable to get into a state where places was making datastore requests during the notificaiton. I think it might be a red herring, and the real cause might be something else. To proceed I think we're going to need additional information.

Mac - could you provide us with a memory dump using get_about_memory.py? This should help us narrow down what to look into next. Validating the repro steps and profile, or providing a video might also help. Thanks!
Flags: needinfo?(kgrandon) → needinfo?(zrzut01)
Can QA reproduce?
Keywords: qawanted
I wonder if this could come from the SMS application itself? Because in background we're actually rendering a full SMS application including rendering conversations.

This is mostly history from past days, but this is also quite nice because when the user taps the notification, the SMS application is actually ready. UX would need to tell us if this is something we'd want or if we'd rather close the application after sending the notification.
(Reporter)

Comment 13

3 years ago
I sent the mem dump to :kgrandon. If anyone wish to get access to the dump please contact with him.
Flags: needinfo?(zrzut01)
QA Contact: bzumwalt
Seeing this issue occur on Flame 2.1, 2.2, and 3.0

Using the command "adb shell top -m 5" to test, observed CPU spike when message is received while screen is off appears nearly the same as when receiving SMS while on Homescreen. Tested empty messages app with no previous SMS's as well as SMS inbox filled using make-reference workload. Only seeing massive 50%+ spike during the first few tests, continuing to test on device sees spikes gradually drop off to around no more than 20%.

Device: Flame 2.1
BuildID: 20150113001255
Gaia: 836e6d74cb8b7016df555f85445893b3ff9aac12
Gecko: 074f79a929d2
Version: 34.0 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2
BuildID: 20150113002520
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: df130262b09e
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 3.0 Master
BuildID: 20150113010202
Gaia: 9946a490a9264b42e65385d703b28fa055ab2d42
Gecko: 3d846527576f
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
status-b2g-master: --- → affected
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
(In reply to Brogan Zumwalt [:BroganZ] from comment #14)
> Seeing this issue occur on Flame 2.1, 2.2, and 3.0
> 
> Using the command "adb shell top -m 5" to test, observed CPU spike when
> message is received while screen is off appears nearly the same as when
> receiving SMS while on Homescreen. Tested empty messages app with no
> previous SMS's as well as SMS inbox filled using make-reference workload.
> Only seeing massive 50%+ spike during the first few tests, continuing to
> test on device sees spikes gradually drop off to around no more than 20%.

Yeah, because if the SMS app is already launched in background, we don't launch it again obviously.

I think that with a reference workload, you'll have the "50%" spike during a longer time.
Back to SMS based on comment 14.
Component: Gaia::System → Gaia::SMS
Just want to note to triagers: this is really a UX question, see comment 12. I'm fine with changing the behavior. However maybe it should not be a blocker because this is how it works since v1.0.
triage: non-blocker. (Refer to comment 12 and comment 17).
blocking-b2g: 2.2? → -
tracking-b2g: --- → backlog
Mass closing of Gaia::SMS bugs. End of an era :(
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.