Overhauling the process priority manager

[Gabriele Svelto]

TL; DR The process priority manager has accumulated a fair amount of
technical baggage and is in need of an overhaul. I'm proposing a bunch
of changes here as well as some historical perspective and the rationale
for those changes. This is not a very well known topic so if you don't
know this area you might want to take a dive too so that you're aware of
how FxOS application priorities are handled.

Hi everybody,
I've been sitting on some ideas on how to improve our priority
management in FxOS and I think it's time to start discussing the topic
because some choices we made in the original design have proven to be
fragile and we could use some improvements.

A little bit of history first; the process priority manager
(dom/ipc/ProcessPriorityManager.[h|cpp]) was designed in the early days
of the project with two roles in mind: to maximize application
responsiveness by adjusting CPU priorities and to keep relevant
applications alive by adjusting LMK scores.

The earliest design assigned both CPU priorities and LMK scores based on
application visibility (favoring foreground applications) and wakelocks
but were not affected by the state of other applications.

As we came close to delivering our first version a number of usability
bugs cropped up which forced changes to be made to account for scenarios
in which all applications should have been deprioritized except for one
(e.g. incoming call) as well as making certain exceptions for "special"
applications.

This lead us to partially split CPU priorities from LMK scores (but not
really) and made us special-case the homescreen (which has higher
priority than any other background app), the preallocated process (which
we don't want to kill because of memory pressure) and the keyboard
(which is considered in the foreground when visible, but less important
than the app itself). Once we were done the process priority manager had
become a collection of corner cases and obscure logic which made
modifying it and improving it complicated (e.g. see the fallout of bug
874353 [1]).

So I'm proposing a few radical changes to reduce the complexity of the
manager and improve some aspects of it that are currently lacking IMHO.

1) First of all I'd like to *really* decouple the LMK scores and CPU
priority levels. This should simplify the logic as well as saving us the
hacks we put in place (and relative assertions) to ensure we don't blow
the limit of 6 free memory thresholds that the kernel imposes on us.
Changing priorities should probably also be done on a global basis so
that we know early in the process if we're affecting only one process or
multiple ones.

2) Currently the manager more or less assumes that there's only one
foreground app. If it needs to be special (e.g. the dialer during a
call) it can get higher priority. This doesn't map very well to certain
scenarios where we have multiple apps visible (because of an attention
screen, or simply because we don't set the visibility flag correctly,
bug 892371 [2], bug 846850 [3]). If multiple apps are considered in the
foreground they'll all get the same priority and this usually leads the
LMK to kill the larger of them if we run out of memory. This is almost
always the *wrong* choice as the largest application is often the one
being actively used. To mitigate this issue I'd like to keep foreground
apps in an LRU queue with decreasing priority like we do with background
apps. This should make us pick the right app for killing when we run out
of memory without requiring further information from gaia.

3) Remove the special class that makes the homescreen process more
important than other processes and rely on LRU priorities for background
apps. Why? Because this is both suboptimal and leads to all sorts of
problems. For example when turning off the device screen the foreground
app becomes hidden and is thus sent into the background. If memory is
tight the LMK will look for an app to kill and will usually find the
large, former foreground app since it's now less important than the
homescreen. The user will turn on the phone again and find himself on
the homescreen with no clue as to why his app was closed. Similarly when
using the new navigation paradigm of swiping between applications the
older applications will be killed before the homescreen but that's
silly, if the user is not using the homescreen to switch between those
and just sliding between them we should be keeping the apps open not the
homescreen. So how do we solve this? By making the homescreen a regular
app and relying on the LRU nature of background priorities to keep it
alive. If the user is using the homescreen to switch between apps the
LRU logic will always consider it the most important of the background
apps and the LMK will kill the other apps before killing it, effectively
reproducing the current behavior but without special-casing it. If on
the other hand the user is swiping between applications, the homescreen
will drop to the least important priority and be killed freeing memory
for the apps the user is actively using so both scenarios should be
equal or better than they are now.

4) Compute the LMK memory thresholds automatically whenever possible. We
currently configure the levels of free memory at which applications
should be killed in the prefs. This is a very inflexible approach and
requires vendors to fine tune the values for their devices or take
suboptimal values (the default ones were meant for 256MiB devices with
~180MiB of memory available to userspace applications). Instead we could
compute those values as a percentage of the available memory and scale
them automatically (using the current values as references for 256MiB
devices since they work well there). We might want to keep around the
mechanism to override them via prefs but in general it would be better
if the defaults are set automatically.

So this is it more or less. Sorry for the lengthy e-mail but it's two
years worth of brain dump. For those interested we've got a metabug for
this, it's bug 994518 [4]. Comments are *very* welcome.

Gabriele

[1] Remove CPU wake lock control from ContentParent
https://bugzilla.mozilla.org/show_bug.cgi?id=874353
[2] [Activity] Adjust OOM score of activity opener
https://bugzilla.mozilla.org/show_bug.cgi?id=892371
[3] [Unagi][Camera][Activity][Contacts] App doesn't get
'mozvisibilitychange' event when running as an activity
https://bugzilla.mozilla.org/show_bug.cgi?id=846850
[4] [B2G] Improve priority manager of B2G for better performance
https://bugzilla.mozilla.org/show_bug.cgi?id=994518

[Fabrice Desré]

Hi Gabriele,

Thanks for writing this and making things move forward, this is very
much needed!

One question: do you think it would be worthwhile to have more direct
signals from the system app on what app is important or not? I see that
in your proposals you still relies on somewhat indirect hints like
visibility, etc. The system app is part of the platform for all
practical matters so it's ok from an overall architecture point of view.

Fabrice

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>


--
Fabrice Desr�
b2g team
Mozilla Corporation

[Jonas Sicking]

On Thu, Aug 28, 2014 at 9:39 AM, Gabriele Svelto <gsv...@mozilla.com> wrote:
> Comments are *very* welcome.

Hey, thanks for looking into this. I agree that it's badly needed.

I have a couple of concerns, however I'm mainly happy to ultimately
defer to others, such as yourself, that has looked at this stuff more
than I have.

First off, I'm somewhat concern about not giving the homescreen any
special treatment. It seems to me that even for users that swipe
between apps a lot, going to homescreen is going to be a relatively
common action.

It sounds like the perfect solution here would be some form of
predictive algorithm, or something based on frecency. But that sounds
like a lot of complexity.

But especially once we add support for application scopes [1], it
might be common to navigate between applications without going through
the homescreen each time. But still for users to more often return to
the home screen than to the app that they used one or two apps ago.

I agree that it's bad that the homescreen gets higher priority than
the "front most" app when the screen is turned off. But that sounds
fixable without completely making homescreen be "just another app".
Maybe one solution is to use LRU, but prevent homescreen from dropping
below 3rd place?


Second, I'm missing mention of special treatment of apps that play
background music. I definitely think that if an app is playing audio
while in the background, that we need to give higher priority than
almost every other background app. This is both because it's directly
noticeable to the user when we kill the app, and because if the app is
playing audio, that audio is likely something that the user wants to
listen to.

I would actually say that apps that play audio, including the dialer,
likely should always have higher priority than any background app. If
there are multiple apps that are doing this, then using an LRU seems
fine.


Third, when I have pondered this stuff in the past, it seemed to me
like a lot of the complexity comes from the fact that the system app
generally had most of the information about which app is most
important. However gecko made all the decisions. And the only way that
the system app could influence gecko was through setting various
properties through the browser API which only affected LMK levels CPU
priorities in indirect and complex ways.

Did you give any thoughts to simply give the system app more direct control?

[1] https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Ufrz9UW-Z28

/ Jonas

[Gabriele Svelto]

On 29/08/2014 20:37, Fabrice Desré wrote:
> One question: do you think it would be worthwhile to have more direct
> signals from the system app on what app is important or not? I see that
> in your proposals you still relies on somewhat indirect hints like
> visibility, etc. The system app is part of the platform for all
> practical matters so it's ok from an overall architecture point of view.

Currently we're relying on the following information:

- visibility, used to establish background (hidden) and foreground
(visible) priority
- cpu/high-priority wakelocks, used to boost priority to both foreground
and background apps
- system message handlers, used to boost priority if the app has pending
messages in the handlers it registered
- audio output to boost priority of background apps playing audio
- app type, we currently special-case the keyboard (which is less
important than other foreground apps) and homescreen (which is more
important than background apps but less important than background apps
playing audio)

This has worked relatively well for us except when activities were
involved where we had multiple foreground apps. Now the presence of the
search bar (which is always visible for practical purposes) is also
making this more complicated.

I've given some thought about relying on explicit commands from the
system app but it sounds to me as that would be effectively moving the
priority assignment logic out of gecko and into gaia. Would that be a
good thing? I think that information such as audio playback and wakelock
control and system messages is not available there so that would need to
be handled in gecko anyway.

Visibility on the other hand might be better handled in the system app
since it's aware of "external" connections between the app such as
activity chains. Special-casing apps could also be done better in the
system app (note that we recently had problems because the keyboard app
changed an attribute name and the priority manager couldn't tell it
apart from other apps anymore).

Naturally we would need some kind of exposed API to allow the system app
to communicate this information to Gecko. Maybe a basic set of
priorities associated with an app.

Gabriele

[Alive]

This has worked relatively well for us except when activities were 
involved where we had multiple foreground apps. Now the presence of the 
search bar (which is always visible for practical purposes) is also 
making this more complicated. 

The searchBar is part of the system app, but the search app window is not.

If system app does send the search window to background correctly when it is not invoked, is this still an issue?

I've given some thought about relying on explicit commands from the 
system app but it sounds to me as that would be effectively moving the 
priority assignment logic out of gecko and into gaia. Would that be a 
good thing? I think that information such as audio playback and wakelock 
control and system messages is not available there so that would need to 
be handled in gecko anyway. 

We are *highly* willing to move the audio competing policy from gecko to gaia…

because there is still something needs to be determined by system app but now in gecko we are handling it badly.

though even we have better setVisibile API() in https://bugzilla.mozilla.org/show_bug.cgi?id=1034001

I am not sure how difficulty about exposing the wake lock and system message,

but please note that system app is also playing an important role on these:

* Set mozPower attribute when wake-lock is got in screenManager

* Launch related apps required by system message event(open-app)

Visibility on the other hand might be better handled in the system app 
since it's aware of "external" connections between the app such as 
activity chains. Special-casing apps could also be done better in the 
system app (note that we recently had problems because the keyboard app 
changed an attribute name and the priority manager couldn't tell it 
apart from other apps anymore). 

For activity chaining, we are doing it by force all apps involved in the chaining to be foreground, and this is definitely not good.

Naturally we would need some kind of exposed API to allow the system app 
to communicate this information to Gecko. Maybe a basic set of 
priorities associated with an app. 

I was +1 to this idea from long time ago.

get/get Priority/Nice value…or something like that.

Thanks for bringing the priority management issue up.

Gabriele 

[Thinker K.F. Li]

Jonas Sicking <jo...@sicking.cc> writes:

> On Thu, Aug 28, 2014 at 9:39 AM, Gabriele Svelto
> <gsv...@mozilla.com>
wrote:
>> Comments are *very* welcome.
>

...... skip ......

>
> Third, when I have pondered this stuff in the past, it seemed to
> me
> like a lot of the complexity comes from the fact that the system
> app
> generally had most of the information about which app is most
> important. However gecko made all the decisions. And the only
> way that
> the system app could influence gecko was through setting various
> properties through the browser API which only affected LMK
> levels CPU
> priorities in indirect and complex ways.

I am afraid it would be inefficient for the longer response time.
For example, we would prefer to give the dialer a highest priority
for ringing. So, we would try to lower the priority of the music
player process at first monent if there is. The path of ring from
RIL to system app is far too long/slow for some stressed
circumstances. One solution is to break layers and pass events;
like ring, to the system app through a shortcut, then we will
expose a lot implementation details to the system app.

It is good to move the decision alogrithm out of Gecko, but I
would like to keep it as an native module until these issues are
fixed.

>
> Did you give any thoughts to simply give the system app more
> direct
control?
>
> [1]
https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Ufrz9UW-Z28
>
> / Jonas

--
Sinker
--
天教懶漫帶疏狂

[Gabriele Svelto]

On 30/08/2014 01:05, Jonas Sicking wrote:
> First off, I'm somewhat concern about not giving the homescreen any
> special treatment. It seems to me that even for users that swipe
> between apps a lot, going to homescreen is going to be a relatively
> common action.
>
> It sounds like the perfect solution here would be some form of
> predictive algorithm, or something based on frecency. But that sounds
> like a lot of complexity.

Yes, I'd rather avoid complexity. The idea of special-casing the
homescreen was important back in the day because restarting it took
significant time and the user could wait a few seconds before seeing the
icons. I don't know if this is the case anymore with the vertical
homescreen. If restarting it is quick enough then there's no point in
keeping it artificially alive.

> I agree that it's bad that the homescreen gets higher priority than
> the "front most" app when the screen is turned off. But that sounds
> fixable without completely making homescreen be "just another app".
> Maybe one solution is to use LRU, but prevent homescreen from dropping
> below 3rd place?

I have to think about that. The
foreground-app-goes-to-the-background-when-the-phone-is-turned off is
kind of complicated to solve in a robust way right now. It's fixable and
I've got a patch already to solve it but it's somewhat fragile.

> Second, I'm missing mention of special treatment of apps that play
> background music. I definitely think that if an app is playing audio
> while in the background, that we need to give higher priority than
> almost every other background app. This is both because it's directly
> noticeable to the user when we kill the app, and because if the app is
> playing audio, that audio is likely something that the user wants to
> listen to.
>
> I would actually say that apps that play audio, including the dialer,
> likely should always have higher priority than any background app. If
> there are multiple apps that are doing this, then using an LRU seems
> fine.

Yes, I forgot mentioning it but we're already boosting the priority of
apps playing audio in the background. That wouldn't change naturally.

> Third, when I have pondered this stuff in the past, it seemed to me
> like a lot of the complexity comes from the fact that the system app
> generally had most of the information about which app is most
> important. However gecko made all the decisions. And the only way that
> the system app could influence gecko was through setting various
> properties through the browser API which only affected LMK levels CPU
> priorities in indirect and complex ways.

Yes, your mail as well as Fabrice's and Alive's answers are making me
warm up to the idea of moving some of these decisions into the system app.

Gabriele

[Cervantes Yu]

On 08/30/2014 07:05 AM, Jonas Sicking wrote:
> On Thu, Aug 28, 2014 at 9:39 AM, Gabriele Svelto <gsv...@mozilla.com> wrote:
>> Comments are *very* welcome.

> Hey, thanks for looking into this. I agree that it's badly needed.
>
> I have a couple of concerns, however I'm mainly happy to ultimately
> defer to others, such as yourself, that has looked at this stuff more
> than I have.
>

> First off, I'm somewhat concern about not giving the homescreen any
> special treatment. It seems to me that even for users that swipe
> between apps a lot, going to homescreen is going to be a relatively
> common action.
>
> It sounds like the perfect solution here would be some form of
> predictive algorithm, or something based on frecency. But that sounds
> like a lot of complexity.
>

> But especially once we add support for application scopes [1], it
> might be common to navigate between applications without going through
> the homescreen each time. But still for users to more often return to
> the home screen than to the app that they used one or two apps ago.
>

> I agree that it's bad that the homescreen gets higher priority than
> the "front most" app when the screen is turned off. But that sounds
> fixable without completely making homescreen be "just another app".
> Maybe one solution is to use LRU, but prevent homescreen from dropping
> below 3rd place?
>
>

> Second, I'm missing mention of special treatment of apps that play
> background music. I definitely think that if an app is playing audio
> while in the background, that we need to give higher priority than
> almost every other background app. This is both because it's directly
> noticeable to the user when we kill the app, and because if the app is
> playing audio, that audio is likely something that the user wants to
> listen to.
>
> I would actually say that apps that play audio, including the dialer,
> likely should always have higher priority than any background app. If
> there are multiple apps that are doing this, then using an LRU seems
> fine.
>
>

> Third, when I have pondered this stuff in the past, it seemed to me
> like a lot of the complexity comes from the fact that the system app
> generally had most of the information about which app is most
> important. However gecko made all the decisions. And the only way that
> the system app could influence gecko was through setting various
> properties through the browser API which only affected LMK levels CPU
> priorities in indirect and complex ways.

I agree it is desirable that the system app gains more control over
which app has a higher priority. But please note that many signals are
considered low-level implementation details that is only available in
gecko. If we are to delegate the decision making to the system app, we
may find it necessary to continue exposing low-level details to the
system app. For example, we could take swap (zram) usage or memory usage
pattern (dropping cache-intensive app first) into consideration in
deciding app priority.

Maybe we should keep in gecko a generic algorithm involving all the
implementation details, but open a door to the system app to let it fine
tune app priorities based on the information available in the system app.

--
Cervantes Yu
Mozilla Taiwan

> Did you give any thoughts to simply give the system app more direct control?
>
> [1] https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Ufrz9UW-Z28
>
> / Jonas

[Jonas Sicking]

On Mon, Sep 1, 2014 at 3:07 AM, Gabriele Svelto <gsv...@mozilla.com> wrote:
> I've given some thought about relying on explicit commands from the
> system app but it sounds to me as that would be effectively moving the
> priority assignment logic out of gecko and into gaia. Would that be a
> good thing? I think that information such as audio playback and wakelock
> control and system messages is not available there so that would need to
> be handled in gecko anyway.

I don't mind at all having the system app handle more of these things.
Moving the logic from gecko to gaia means that we have more code which
is running in JS rather than C++ which generally is a good thing.
Additionally, gaia does have access to a lot more information about
various UI edge cases than Gecko does, which should mean less
guess-work and more accurate algorithms.

The system app does have access to wakelocks already. And there's
various audio policies that we'd like to implement which I think would
be easier to implement by giving the system app access to audio
information. So I suspect that we'll get that too no matter what.

Thinker is pointing out one important problem that we'd need to solve
though. At least for when we are receiving a phone call, it is
important that we are able to as quickly as possible launch the
process for the dialer app and give it a high CPU and LMK priority.
But that seems solvable even if most of the other processing is
happening through the system app.

/ Jonas

[Jonas Sicking]

On Mon, Sep 1, 2014 at 4:39 AM, Thinker K.F. Li <thi...@codemud.net> wrote:
> Jonas Sicking <jo...@sicking.cc> writes:
>
>> On Thu, Aug 28, 2014 at 9:39 AM, Gabriele Svelto <gsv...@mozilla.com>
>
> wrote:
>>>
>>> Comments are *very* welcome.
>>
>>

> ...... skip ......

>
>>
>> Third, when I have pondered this stuff in the past, it seemed to me
>> like a lot of the complexity comes from the fact that the system app
>> generally had most of the information about which app is most
>> important. However gecko made all the decisions. And the only way that
>> the system app could influence gecko was through setting various
>> properties through the browser API which only affected LMK levels CPU
>> priorities in indirect and complex ways.
>

> I am afraid it would be inefficient for the longer response time. For
> example, we would prefer to give the dialer a highest priority for ringing.
> So, we would try to lower the priority of the music player process at first
> monent if there is. The path of ring from RIL to system app is far too
> long/slow for some stressed circumstances. One solution is to break layers
> and pass events; like ring, to the system app through a shortcut, then we

> will expose a lot implementation details to the system app.

Where is the extra overhead coming from?

Is it because we have to go through the main thread in the parent process?

Or is it because the system app is doing a lot of JS processing before
it actually creates an <iframe mozbrowser> element?

Or is it because we run a lot of gecko code between the <iframe
mozbrowser> element has been created and we actually start talking to
the pre-forked app process?

Or is it something else?

/ Jonas

[Thinker K.F. Li]

From: Jonas Sicking <jo...@sicking.cc>
Subject: Re: [b2g] Overhauling the process priority manager
Date: Mon, 1 Sep 2014 20:52:19 -0700

> On Mon, Sep 1, 2014 at 4:39 AM, Thinker K.F. Li <thi...@codemud.net> wrote:
>> Jonas Sicking <jo...@sicking.cc> writes:
>>

>>> On Thu, Aug 28, 2014 at 9:39 AM, Gabriele Svelto <gsv...@mozilla.com>
>>
>> wrote:
>>>>
>>>> Comments are *very* welcome.
>>>
>>>

>> ...... skip ......

>>
>>>
>>> Third, when I have pondered this stuff in the past, it seemed to me
>>> like a lot of the complexity comes from the fact that the system app
>>> generally had most of the information about which app is most
>>> important. However gecko made all the decisions. And the only way that
>>> the system app could influence gecko was through setting various
>>> properties through the browser API which only affected LMK levels CPU
>>> priorities in indirect and complex ways.
>>

>> I am afraid it would be inefficient for the longer response time. For
>> example, we would prefer to give the dialer a highest priority for ringing.
>> So, we would try to lower the priority of the music player process at first
>> monent if there is. The path of ring from RIL to system app is far too
>> long/slow for some stressed circumstances. One solution is to break layers
>> and pass events; like ring, to the system app through a shortcut, then we
>> will expose a lot implementation details to the system app.
>
> Where is the extra overhead coming from?
>
> Is it because we have to go through the main thread in the parent process?
>
> Or is it because the system app is doing a lot of JS processing before
> it actually creates an <iframe mozbrowser> element?
>
> Or is it because we run a lot of gecko code between the <iframe
> mozbrowser> element has been created and we actually start talking to
> the pre-forked app process?
>
> Or is it something else?

Passing a ring message from ril worker to system app could
take several hundred ms.

There several circumstances contribute to the latency. One of the
source of the latency comes from memory pressure. We could expect a
lot of code and data are removed out of the cache of the kernel on the
path of handling ring events. It costs a lot of time to load the code
back from the flash (native) and swap (for JS code and data), and it
would compete with other running processes for the cache; music
player for example.

>
> / Jonas

[Gabriele Svelto]

Hi Alive,
I've been sidetracked by other issues so here's my late answer...

On 01/09/2014 12:23, Alive wrote:
> The searchBar is part of the system app, but the search app window is not.
>
> If system app does send the search window to background correctly when
> it is not invoked, is this still an issue?

That's a good question. Some time ago the search app window was
considered always in the foreground but now it's properly moved to the
background once it's dismissed so that seems to work fine.

> We are *highly* willing to move the audio competing policy from gecko to
> gaia…
>
> because there is still something needs to be determined by system app
> but now in gecko we are handling it badly.

Right now as far as the process priority manager is concerned this is
fairly straightforward, we just check if the PID is playing something:

http://hg.mozilla.org/mozilla-central/file/738469449872/dom/audiochannel/AudioChannelService.cpp#l496

Where you thinking of moving the AudioChannelService into Gaia? I'm not
very familiar with how that code works so I can't really comment.

> I am not sure how difficulty about exposing the wake lock and system
> message,

I'd keep wake-lock information handled at the Gecko level. It's really
simple there (the priority manager is just waiting for notifications)
and it's important to guarantee quick reaction times in important
situations. For example grabbing the high priority lock in the dialer is
only a few C++ calls away from having all other applications downgraded
to the last priority level. This has proven to be critical for not
missing incoming calls in loaded scenarios. Also see bug 874353 [1].

> * Launch related apps required by system message event(open-app)

The system message situation is already improving IIRC, see bug 1046033
[2]. One important aspect regarding starting applications however
pertains to the visibility state. If we could inform the priority
manager that an app needs a healthy CPU boost at the very beginning of
its launch process we might gain something compared to the current
situation where we have to wait for it to become visible.

> For activity chaining, we are doing it by force all apps involved in the
> chaining to be foreground, and this is definitely not good.

Yes, this is why I was considering using an LRU arrangement for
foreground apps.

> I was +1 to this idea from long time ago.
>
> get/get Priority/Nice value…or something like that.

OK, so here's a concrete proposal. The visibility information is the
first thing we could consider replacing with more direct control in the
system app as well as special-casing of apps.

Let's say we add a "priority" field to the DOMApplication object with an
associated permission to manipulate it which would be given only to the
system app.

To keep things simple this field would support 5 priority levels which
would correspond to the current BACKGROUND, BACKGROUND_HOMESCREEN,
BACKGROUND_PERCEIVABLE, FOREGROUND_KEYBOARD, FOREGROUND. We don't need
to call them that way naturally. Once this is done we'd have the system
app set them to match the current policy and we'd simultaneously remove
the visibility information and homescreen/keyboard special-casing from
the priority manager and replace it with the assigned priority level.

What do you think? I'd like to start simple because I feel we should be
removing as much complexity as possible but do so in a gentle,
incremental way.

Gabriele

[Gabriele Svelto]

On 02/09/2014 05:18, Jonas Sicking wrote:
> Thinker is pointing out one important problem that we'd need to solve
> though. At least for when we are receiving a phone call, it is
> important that we are able to as quickly as possible launch the
> process for the dialer app and give it a high CPU and LMK priority.

For now I'd keep the process priority manager watch the wakelock changes
instead of delegating that job to the system app. As far as grabbing
wakelocks for calls go we don't have much of a problem because the
callscreen lives in the system app now and thus is running at the
highest possible priority anyway. When we'll split it out though this
might be important again.

One thing that we're missing right now IIRC is a way to pass a wakelock
from the platform code to the app code. In a lot of scenarios (e.g. bug
932698 [1]) it would be very useful if the platform code could grab a
wakelock on behalf of the app; then once the relevant app has started
the wakelock should be passed on to it to prevent a scenario where the
platform releases its wakelock before the app can grab it itself. This
is another problem though and possibly worthy of a separate discussion.

Gabriele