On 16/11/2013 11:24, Andreas Gal wrote:
Nice analysis. Idea 1 you might be onto something. Maybe NuWa rebalanced our memory equation here?
Yes, it would be worth to re-evaluate our parameters for NUWA as the current settings were tailored before it. In addition to that, those parameters were also geared for 256MiB devices that had ~180MiB of memory available to userspace. We have a bug (886278) for re-evaluating them for devices with more memory.
I had posted a proposal there to make those and other values dynamically computed depending on the total amount of free memory but didn't have time to follow-up on that:
https://bugzilla.mozilla.org/show_bug.cgi?id=886278#c10 Maybe it's time that I prioritize this stuff.
This code is a bit under-owned for the last months, so if you find someone suspicious, chances are, its broken.
Yeah, I happen to know this part quite well and I should really be doing a write up. I've opened a bug for it so that we can track it and I won't forget:
https://bugzilla.mozilla.org/show_bug.cgi?id=939415
If the OOM condition gets worse the background processes will get reaped, which is not a bad thing, and suiciding them early probably doesn't benefit us much. I might be wrong..
Actually we kill background applications before sending memory-pressure notifications. The rationale behind it is that on the one hand background applications have already been minimized so there's not much to gain there and on the other hand keeping them alive might be detrimental.
The archetypal example of why it's bad to keep background apps alive is the following: the phone's busy with lots of apps but the dialer has not been launched yet. An incoming call arrives triggering the dialer to start up, this will cause a spike in memory consumption as we make room for it.
If we send a memory-pressure notification at this stage we will: a) potentially save busy apps which might load the CPU at a time where we need to react fast, b) generate a storm of CPU activity as all background apps wake up and run the GC and finally c) slow down the dialer by telling it to also run the GC*
The end result is that we'll often miss the incoming call. Killing the background apps on the other hand decreases the chance of CPU time and memory being diverted from what most needs it.
Dialer aside this also applies to starting any app; what I described above is likely to make app startup slower under this common scenario.
Another situation where we want to kill background apps before sending memory-pressure notifications is that of badly behaved apps. Imagine an app that's misbehaved and keeps churning through memory after being sent to the background. If we send low-memory notifications before killing background apps we'll keep it alive indefinitely and routinely exercise the GC. With the current setup on the other hand such an app has a high chance of being culled by the oom killer which is a Good Thing™.
Gabriele (*) c) is in fact still a problem, I'm working on it in bug 873284 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
