Composing time becomes much longer randomly when we unplug the usb cable on flame-kk device

NEW
Assigned to

Status

()

defect
5 years ago
3 years ago

People

(Reporter: jerry, Assigned: jerry)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 5 obsolete attachments)

When we turn on vsync on flame-kk, with OMTA animation, we got a very uniform composing time for each frame. Bug if we unplug the usb cable, we can see a lot of janks during animation.

If we force to use the performance cpu governor, we will not see this issue.
  adb shell "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

I think it might related to cpu power module.

Android provide some performance hint for user[1].
I set both POWER_HINT_VSYNC and POWER_HINT_INTERACTION hint into our power module in GonkDisplay[2], but it seems not work.

[1]
http://androidxref.com/4.4.4_r1/xref/hardware/libhardware/include/hardware/power.h
[2]
http://dxr.mozilla.org/mozilla-central/source/widget/gonk/libdisplay/GonkDisplayJB.cpp?from=GonkDisplayJB.cpp&case=true#158
Posted file adbwifi.sh
I use this script to turn on wifi adb for device.

1) turn on the wifi on device and connect to your ap
2) ./adbwifi.sh
   if success, you will see "connected to x.x.x.x:5555"
3) unplug the usb cable

After that, I can do profile without usb cable.
Blocks: 1123762
Assignee: nobody → hshih
We don't have the power module source code for flame device, so I use nexus5-l instead.
In b2g/hardware/qcom/power/power.c, it will write some data to "/dev/socket/pb" with POWER_HINT_INTERACTION hint. And the unix domain socket "/dev/socket/pb" seems created by mpdecision. I can't trace the mpdecision either. Still tracking.

  case POWER_HINT_INTERACTION:
    touch_boost();
    break;
  case POWER_HINT_VSYNC:
    //do nothing
    break;
Is it a good idea having a module in gonk to set the cpu governor in gecko? Since we might not always have a power module to handle the android "POWER_HINT_INTERACTION" and "POWER_HINT_VSYNC" hint. Maybe we should write our power hint module.
When we have touch data or enable the vsync, we change the governor as [1].

[1]
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Flags: needinfo?(mwu)
Posted patch cpu governor hint. v1 (obsolete) — Splinter Review
Posted patch cpu governor hint. v2 (obsolete) — Splinter Review
Attachment #8561805 - Attachment is obsolete: true
Here is the profile result for omta animation with power hint.
With performance mode, we still can't recover the long compositor composing time.
At the moment, configuration of the cpu governor is the responsibility of the vendor. This usually makes the most sense since CPU speed needs to also take thermal conditions into account. More complicated things like ARM big.LITTLE usually have their own cpu governor (AIUI), so we can't even assume a particular governor.
Flags: needinfo?(mwu)
Create a new power module to handle all power related function. It also moves all power related code from GonkDisplay to this GonkPower module.
Attachment #8561813 - Attachment is obsolete: true
Comment on attachment 8568969 [details] [diff] [review]
create a new gonk power module

It's hard to configure the cpu governor by ourself, but we still have the android's power hint. No matter our vender implements the hint or not, I think we still can set the hint to the power module.

This patch create a new power module to export the following power hint[1] from android. I also move all power module related code from GonkDisplay to this module to make GonkDisplay much clearer. Then, we set the hint as the attachment 8568970 [details] [diff] [review].

[1]
http://androidxref.com/4.4.4_r1/xref/hardware/libhardware/include/hardware/power.h#41
Attachment #8568969 - Flags: feedback?(mwu)
Not sure what the purpose of that patch is. It doesn't seem any easier to understand if you move it to another file.
Flags: needinfo?(hshih)
Attachment #8568969 - Attachment is obsolete: true
Attachment #8568969 - Flags: feedback?(mwu)
Attachment #8577140 - Flags: feedback?(mwu)
Flags: needinfo?(hshih)
Flags: needinfo?(jgomez)
Flags: needinfo?(gsvelto)
Flags: needinfo?(fatseng)
Hi Alexandre,
What do you want to discuss?
Flags: needinfo?(fatseng)
(In reply to Farmer Tseng from comment #14)
> Hi Alexandre,
> What do you want to discuss?

Well this is aligned with the email thread about PowerHAL and luckily I found this bug. Maybe we should work on fixing that? And verify if maybe there is a problem on Flame KK and not on other devices since we now have other devices ?
This might be useful/interesting for you
Flags: needinfo?(gsvelto)
Flags: needinfo?(felash)
Does not seem to change anything for me, but I haven't tried during a long time.
Flags: needinfo?(felash)
I've finally got time to try this out. One good test case is the lockscreen: with the Flame unplugged scrolling the lock icon on the bottom is very janky (like ***VERY*** janky, it looks like it's doing 3-4FPS). With the cable plugged it's super-smooth so if this fixes that particular scenario I think it fixes all of them.
Scratch my previous comment, after further testing with Julien it seems that's does't always happen and may be unrelated :-/
I'm trying to profile the compositor thread but for some reason it doesn't work, I use this command:

./profile.sh -p b2g -i 1 -t GeckoMain,Compositor

but when I capture the profile I only get data from the GeckoMain thread... I'm I doing something wrong?
Clearing the ni for now since this is not super-important right now but I'll definitely come back and have a look once we're done with the transitioning effort.
Flags: needinfo?(gsvelto)
Flags: needinfo?(jgomez)
Attachment #8577140 - Flags: feedback?(mwu.code)
You need to log in before you can comment on or make changes to this bug.