On 09/01/2015 08:58, Tim Guan-tin Chien wrote: > I presume this will impact behavior of apps around app-switching, e.g. > any app that do any significant clean-up when receiving > visibilitychange will be slow down. Is that correct?
It depends on how much CPU is available. On single-core devices this
would be the case if the new foreground app would keep the CPU busy all
the time. In case of dual-core+ SoCs this will never happen in practice.
You can check this by monitoring CPU utilization during an app switch on
the Flame. Using two games is a good fit since they will both try to get
100% CPU utilization. Even for single-core devices though I doubt this
will be a big problem, background apps will be delayed only if it's
needed to guarantee CPU for the foreground one. BTW CPU usage is also
better balanced between the foreground app and the main process.
> I would also afraid such bug show up on v2.2 down the road which will
> be very hard to address. So I wonder if it's possible to disable this
> change in v2.2 branch.
This was actually requested for v2.2 :-) BTW it brings other benefits
too, such as better handling of swapping on devices using zram. Check
Dave's work on bug 1082290 [1] which is also part of the v2.2 scope.
Gabriele
[1] Implement cgroup swappiness feature for low memory target (256 MB)
https://bugzilla.mozilla.org/show_bug.cgi?id=1082290
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
