For now, we change priority of apps when visibility being changed. It is too late for the new launched app don't get god performance for CPU priority and low memory killer. This bug is trying to change priority manager to change priority of processes in fast and correct. Following is a list of some requirements that I think necessary, 1. Change priority setting of processes immediately after launching a new app, 2. Favor dialer for incoming call, (no special priority for any app, even the music app,) 3. Don't change priority setting of last foreground app for lockscreen. From the experience of Tarako, we get the idea of killing background processes ASAP if it would be killed at last. Above items are based on this idea. Item 1 could improve launch time of all apps by new launched one getting better nice value and last foreground app getting easier killed. It improves both CPU scheduling and memory efficiency. Item 2 is to avoid the situation that the music never be killed (very hard). It is not a good for normal. But, for incoming call, launch time of the dialer is important than the music app. Items 3 is to make sure the current foreground app does not get killed for the lockscreen. A suddenly drop of priority could make the process being killed for some extreme conditions.

A few thoughts... Maybe this should be a meta with threee dependent bugs if they can be done one-by-one. For (2), I wonder if we should have a small, stripped down app that just displays the incoming call screen. We could then keep this loaded and ready to go at all times. It could maybe use an activity or lazy load to get the various elements needed after you answer the call.

(In reply to Ben Kelly [:bkelly] from comment #1) > For (2), I wonder if we should have a small, stripped down app that just > displays the incoming call screen. We could then keep this loaded and ready > to go at all times. It could maybe use an activity or lazy load to get the > various elements needed after you answer the call. That's what is being done in bug 990003

I'm taking this as I had started investigating some improvements as part of bug 989713. As already noted we already implemented part of the suggestions in comment 0 and comment 1 in bug 999327 and bug 990003.

We also cherry-pick kernel3.10 patch to firefox kernel. kernel commit 564f73eaa02d152f2d70333d50fb93f6f2a504c9 Author: Yiwen Liu <yiwen.liu@spreadtrum.com> Date: Mon May 5 13:53:42 2014 +0800 Bug #308849 Performance: give selected task higher priority before do LMK [bug number ] [root cause ] [changes ] [side effects] [self test ] compile ok [reviewers ] Change-Id: Ie073940fec0be08071d82a9a322ee3a08869d666

Since Thinker started by suggesting some changes in comment 0 and I feel there's a few more issues which we should address I'd like to convert this into a meta-bug to track issues related to the priority manager and to use it to brainstorm future improvements. I've added a couple of dependencies for this already which include the long standing issue of activities which should be fixed but might require some complex changes. In general we're hitting bugs because the priority manager started with relatively simple logic which involved looking only at an application's status (e.g. if an app is visible it's in the foreground, if it's not it's in the background, if it holds a high priority lock it's important, etc...) but it eventually grew some global conditions and finally had a lot of special-casing applied on top to fix specific use cases (homescreen, keyboard, preallocated process, etc...). These changes, and especially the special-casing of certain apps, has made the logic quite brittle and prone to yielding the wrong results. Going back to Thinker's post points 1 and 3 are really important but are hard to implement using the current setup. In particular we should be able to track global state in a more effective way (how many visible apps are there? In which order where they opened? Etc...) and take that into account when making decisions; we should also provide a proper way to infer special conditions from this state (a new application starting, a high priority application requiring attention) and use that instead of the complex chain logic we currently have. In general making the whole process more deterministic should help a lot; the tests under dom/browser-element/mochitest/priority are pretty messy precisely because they have to follow the convoluted way we currently use to compute and adjust priorities.

I'm adding bug 975360 even though it mentions GC/CC tuning because in practice the whole point is about choosing if/when to minimize a background application and this is currently done as part of process priority management.

not sure if this is really needed for tarako. 1.3T? for discussion

triage: let's put this to backlog

Unassigning myself and officially turning this into a meta-bug.

Bhavana, can you follow up this topic? Thanks.

(In reply to Kevin Hu [:khu] from comment #11) > Bhavana, can you follow up this topic? Thanks. :khu, gabriele will be helping on a couple of dependencies here. Gabriele, I was mainly tracking https://bugzilla.mozilla.org/show_bug.cgi?id=1082290 for 2.2, can you comment all the dependencies are in scope for 2.2 here?

We do want bug 1081871 too for 2.2 and bug 852925 should also be considered. For the former I'm almost done with the patch; for the latter there's already a WIP one I had prepared in the past. It should be refreshed and tested against the current build. If it still works well all associated unit-tests need to be updated because it breaks them. If somebody has some spare cycles to work on that I'd appreciate it because I'm juggling a lot of stuff right now.

(In reply to Gabriele Svelto [:gsvelto] from comment #13) > We do want bug 1081871 too for 2.2 and bug 852925 should also be considered. > For the former I'm almost done with the patch; for the latter there's > already a WIP one I had prepared in the past. It should be refreshed and > tested against the current build. If it still works well all associated > unit-tests need to be updated because it breaks them. If somebody has some > spare cycles to work on that I'd appreciate it because I'm juggling a lot of > stuff right now. Looks like we have feedback+ on 852925 and I've requested review help on 1081871, so hoping these should land soon. Let us know if there are other dependencies that need to be worked on and tracked for 2.2.

Since the bug doesn't block bug 1063044 and also, we should already finish the implementation of 2.2, we can minus this bug with feature-b2g flag. Please raise it if I misunderstood. Thanks.