cbd9a52f256087426feb19ac6e51eff772e81375 |
|
25-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10903002: com.facebook.katana keeps itself in A Services Now when memory low, if a service's process is above a selected pss, then the process is not allowed to go in to the service a list. Also simplified the normal meminfo details dump to not include the shared dirty and shared clean sizes by default, since these can be very confusing. You will still get to see them with the "-a" flag. Finally some small steps to better managing service processes in the LRU list, so hopefully we can some day be better about letting them drop down in the list when there isn't really much interesting happening in the process. Not yet used at this point. Change-Id: I654bfd6d05de2a63120185ebb15ffda8cbeb5dac
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
2610b7cb2a197a3f3f8f7c3409b6962353684159 |
|
21-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10863270: procstats UI is showing all green Gah I messed up when refactoring so it would always be told RAM is low. Also slightly tune the low memory parameters to go into low memory states a bit more aggressively. Change-Id: I5f970349760ad349d515a85c266ab21b387ee353
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
3bc8f78d7a3d23a67c06221cc41292d04a2fd439 |
|
19-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #10691475: Kill cached processes if about to... ...be uncached and too large When the device is in a low RAM state, when we go to pull a cached process out to use for some background operation, we can now kill the current process if we consider its size to be too large. Note that the current implementation for killing processes is to just use the same killUnneededProcessLocked() method that we already have for other things like too many cached processes. This is a little wrong here, though, because in this case we are at the point where the caller is actually looking for a process to use. This current code is not actually removing or cleaning up the process, so we still need to return the now killed ProcessRecord and let things fall out from there, which typically means the caller trying to make an IPC on it and failing and falling into its "oh no the process died unexpectedly" path. All code using this *should* be able to handle this correctly, anyway, since processes really can be killed at any time. At some point we may to make this implementation cleaner, where it actually tears down the process right in the call and returns a null ProcessRecord. That is very dangerous however (we'd need to go through all paths into this to make sure they are going to be okay with process state changing on them like that), and I'm not sure it is really worthwhile. This intention is that killing processes like this is unusual, due to processes being too large, and anyway as I wrote all of our incoming code paths must already be able to handle the process being killed at this point and one could argue this is just another way to excercise those code paths. Really, the main negative to this is that we will often have spam in the log with exceptions about processes dying unexpectedly. If that is the only issue, we could just add some conditions to quiet that up at in this case. We don't want to compute the size of the process each time we try to evaluate it here (it takes 10s or ms to do so), so there is now a new field associated with the process to give us the last pss size we computed for it while it was in the cached state. To be able to have better cached pss data when we now need it, the timing for computing process pss has been tuned to use a much shorter delay for the situations when the process has first switch into a new state. This may result in us having a fair amount more pss data overall, which is good, as long as it doesn't cause us to be computing pss excessively and burning cpu. Procstats now also has new state to keep track of the number of times each process has been killed by this new system, along with the min, avg, max pss of all the times it has happened. This has slightly changed the checkin format to include this additional data at the end of pkgkills/prockills lines. Other changes here: - Fixed a problem where GPU RAM was not being seen when dumping the full RAM details of a process. This was because in that case the system would ask the process to compute its own MemInfo, which it returned, but the process doesn't have permission to access the files containing the GPU RAM data. So now the system always computes the MemInfo and hands it to the app. - Improved broadcast delays to not apply the delay if the next receiver of the broadcast is going to run in the same process as the last one. A situation I was seeing was an application that had two receivers, one of which started a service; we are better off letting the second receiver run while the service is running. - Changed the alarm manager's TIME_TICK broadcast to be a foreground broadcast. This really should have been anyway (it is supposed to go out even minute, on the minute, very accurately, for UI elements to update), and is even more important now that we are doing more things to delay background broadcasts. - Reworked how we maintain the LRU process list. It is now divided into the two parts, the top always containing the processes holding activities. This better matches the semantics we want (always try to keep those around modulated by the LRU order we interleave with other cached processes), and we now know whether a process is being moved on the LRU list because of an activity operation so we can only change the order of these activity processes when user operations happen. Further, this just makes that common code path a lot simpler and gets rid of all the old complexity that doesn't make sense any more. Change-Id: I04933ec3931b96db70b2b6ac109c071698e124eb
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
8e69257a9c7e9c1781e1f53d8856358ada38921d |
|
11-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement #10749688: Improve low memory reporting This significantly reworks the logging we do when all cached processes are killed: - We now collect the list of processes in-place so we have a snapshot of exactly when the low memory situation happened. - In that snapshot we include the key process state: oom adj, proc state, adj reasons. - The report then asynchronously collects pss information for those processes. - The ultimate data printed to the log looks like a mix between the "dumpsys meminfo" and "dumpsys activity" output. This code no longer uses "dumpsys meminfo" itself, so some of that data is no longer included, in particular pss organized by allocation type. In doing this, I realized that the existing code that is supposed to run "procstats" is not currently working. And at that point I realized, really, when we are collecting this pss data we'd really like to include all those native processes using ghod-only-knows how much RAM. And guess what, we have a list of processes available in ProcessCpuTracker. So we now also collect and print information for native processes, and we also do this for "dumpsys meminfo" which really seems like a good thing when we are printing summaries of all pss and such. I also improved the code for reading /proc/meminfo to be able to load all the interesting fields from there, and am now printing that as well. Change-Id: I9e7d13e9c07a8249c7a7e12e5433973b2c0fdc11
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
f1cca18ae460b66242988a8a6204c4a42b6fa1c1 |
|
01-Aug-2013 |
Dianne Hackborn <hackbod@google.com> |
Try to improve PSS collection. The goal is to collect PSS data from processes when they are in as stable a state as possible. We now have tables for the durations to use for PSS collection based on process state, and scheduling of collection is all driven by process state changes. Change-Id: I95e076f6971b9c093118e53dc8240fb3f5bad3b2
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
635a6d5a0b922b5d845b6e2c7ec8453b14fe4b01 |
|
30-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix some oom tuning and display size stuff. Fix a problem where we would not respect the device's override display density/size if those had been reset at some point (to an empty string). Tweak the tuning of low RAM devices to consider 480x800 as the base line resolution. That is our target these days. Improve output of oom and meminfo to include this tuning information. Change-Id: Ic9a85b0391b075178c4ac17e64086ef21889f430
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
59d80a5270249b8b0b32b7ce8e081f4fbd41129a |
|
25-Jul-2013 |
Colin Cross <ccross@android.com> |
set the extra_free_kbytes kernel vm tunable Set the sys.sysctl.extra_free_kbytes property, which will proxy through init to the /proc/sys/vm/extra_free_kbytes tunable (on kernels where it exists). This will ask the kernel to keep more memory free, causing lowmemorykiller to fire earlier and allocations to succeed faster. The size is set to 3 full screen 32bpp buffers. Products can override the size with an absolute or adjustment value using overlays config_extraFreeKbytesAbsolute and config_extraFreeKbytesAdjust. Bug: 10024467 Change-Id: Ib4d4507513ec3c1f4d4ceeb81ed632d1ad643437
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
fcdad6f292a1f83da3bbadc45779ae85307a6f3e |
|
26-Jul-2013 |
Colin Cross <ccross@android.com> |
add overlays to override lowmemorykiller adjustment values Add overlays config_lowMemoryKillerMinFreeKbytesAbsolute and config_lowMemoryKillerMinFreeKbytesAdjust to allow a product to modify the size of the lowmemorykiller minfree buckts. The absolute overlay sets the size of the largest bucket to the specified value and scales the smaller buckets proportionally. The adjust overlay (which can be negative) directly adds to the size of the largest bucket and to the the smaller buckets proportionally. Change-Id: I0d6b7662be12fd151deb2bf9591f2c7a8b1cb6f7
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
637dbfcaf0a1f43f81d3d195461b50bfc0fd5f14 |
|
19-Jul-2013 |
Colin Cross <ccross@android.com> |
Use virtual screen size to determine lowmemorykiller tuning Use the virtual screen resolution returned by getBaseDisplaySize instead of the physical screen resolution returned by getInitialDisplaySize. The memory required by apps will scale with graphics buffer size, which are generally relative to the virtual screen resolution. Change-Id: I0476e4afad99eca2f4f56042a8dbef5b3c7889db
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
c8230519728b14065effd3b7d4eca273ff86160c |
|
14-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Switch proc stats to use new process state constants. These new constants are a better mapping to the kind of information that procstats is wanting to collect about processes. In doing this, the process states are tweaked to have a bit more information that we care about for procstats. This changes the format of the data printed by procstats, so the checkin version is bumped to 2. The structure is the same, however the codes for process states have all changed. The new codes are, in order of precedence: p -- persistent system process. t -- top activity; actually any visible activity. f -- important foreground process (ime, wallpaper, etc). b -- important background process u -- performing backup operation. w -- heavy-weight process (currently not used). s -- background process running a service. r -- process running a receiver. h -- process hosting home/launcher app when not on top. l -- process hosting the last app the user was in. a -- cached process hosting a previous activity. c -- cached process hosting a client activity. e -- cached process that is empty. In addition, we are now collecting uss along with pss data for each process, so the pss checkin entries now have three new values at the end of the min/avg/max uss values of that process. With this switch to using process state constants more fundamentally, I realized that they could actually be used by the core oom adj code to make it a lot cleaner. So that change has been made, that code has changed quite radically, and lost a lot of its secondary states and flags that it used to use in its computation, now relying on primarily the oom_adj and proc state values for the process. This also cleaned up a few problems -- for example for purposes of determing the memory level of the device, if a long-running service dropped into the cached oom_adj level, it would start being counted as a cached process and thus make us think that the memory state is better than it is. Now we do this based on the proc state, which always stays as a service regardless of what is happening like this, giving as a more consistent view of the memory state of the device. Making proc state a more fundamentally part of the oom adj computation means that the values can also be more carefully tuned in semantic meaning so the value assigned to a process doesn't tend to change unless the semantics of the process has really significantly changed. For example, a process will be assigned the service state regardless of whether that services is executing operations in the foreground, running normally, or has been dropped to the lru list for pruning. The top state is used for everything related to activities visible to the user: when actually on top, visible but not on top, currently pausing, etc. There is a new Context.BIND_SHOWING_UI added for when system services bind to apps, to explicitly indicate that the app is showing UI for the system. This gives us a better metric to determine when it is showing UI, and thus when it needs to do a memory trim when it is no longer in that state. Without this, services could get in bad states of continually trimming. Finally, more HashSet containers have been changed to ArraySet, reducing the temporary iterators created for iterating over them. Change-Id: I1724113f42abe7862e8aecb6faae5a7620245e89
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
20cdcee47d10986969e7e2a53a40a6ecabae3827 |
|
11-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Add -c option to meminfo to dump a compact form. Also fix a bug in FastPrintWriter where println(long) was not printing the newline. Change-Id: Idcb4eaab0c1ec4b992032b5e36478ef11a6533d9
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
2286cdc0cab77e61b75e6fe9a45b91f6e57cd46d |
|
02-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Misc memory stuff. - New Activity.reportFullyDrawn() method that applicatins can call when they know they are fully drawn, allowing us to have better app launch time info. This data is also included in usage stats. - Added total and free memory data "dumpsys meminfo". - Tuned the moderate memory levels to be more aggressive about considering the device getting low on RAM, and thus starting to prune RAM from processes. - Fixed issues in processstats when reading old data as well as resetting and other various fixes. Change-Id: I20efe7451afb4edfa1aeec448328ba601c24d869
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
a17c0f5e164729210210ad3f75aea72ed34ca330 |
|
21-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
More procstats work: separate global proc account, more dumping. We now keep track of the time actually process run independently of the time packages run in process, so we can give an accurate summary of how long each physical process runs. New command line options can be supplied to restrict printing to a specific package, dump in a new csv format, control what is printed in the csv format, and print a checkin report. Add toString methods to ArrayMap and ArraySet. Change-Id: I47b8f68472592ecc0088c5286d3564aa615f4e0a
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
78a369c90f61981c9d0ddd5fcbc77202bfbe74f6 |
|
12-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Improve process tracking. We now keep track of when each process is running, batched by the current memory status of the device. In addition, the stats are organized by package first, and then processes associated with each package inside of that. Finally, we also keep track of the overall time spent in each memory status. This should start to actually get us to some information we can reach some conclusions about. The total time spent in each memory status gives us some indication of how much we are running while memory is low; the new package organization batched by memory status lets us see what packages have what processes running when memory is low. Change-Id: I389d62d39d115a846126cf354e4c20070d8f1180
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
be4e6aaa0252dd7da28b7aa85beba982538efa46 |
|
07-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Initial super-primitive process tracker. The goal of this is to keep track of what app processes are doing, to determine who is being abusive, when the system is getting into memory constrained situations, and help the user determine how to resolve this. Right now it doesn't really do any of that, just keeps track of how long every process has been running since boot. Also update the activity manager to use "cached" as the terminology for what it used to interchangeably call hidden and background processes, and switch ProcessMap over to using ArrayMap. Change-Id: I270b0006aab1f38e17b7d9b65728679173c343f2
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
b5cda42c57bc1f965edd73f6bbe1b0d77a933256 |
|
28-Mar-2013 |
Ben Cheng <bccheng@google.com> |
Crank up the mOomMinFreeHigh values by 50%. Devices with 1GB of RAM can benefit from more aggressive OOM killer. BUG: 7972252 Change-Id: Id2b80c14a3cff195c17ef0d14c80b92394649d98
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
b12e1354f25f04e9c9a71da76c6fca858b7d39d0 |
|
26-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #7211766: bindService() to User u0 While u10 is... ...Forground Sometimes Doesn't Take The main change here is a one-liner in ActiveServices to check the uid when deciding whether to remove an item from mPendingServices. This could cause the problem being seen -- if the same service for two users is starting at the same time, the second one would blow away the pending start of the first one. Unfortunately I have had trouble reproducing the bug, so I don't know if this is actually fixing it. It's a bug, anyway. The reason so much has changed here is because I spread around logging and printing of the user ID associated with operations and objects to make it easier to debug these kind of multi-user things. Also includes some tweaks to the oom manager to allow more background processes (I have seen many times in logs where we thrash through processes because the LRU list is too short), plus to compensate an additional time-based metric for when to get rid of background processes, plus some new logic to try to help things like Chrome keep around their service processes. Change-Id: Icda77fb2a1dd349969e3ff2c8fff0f19b40b31d3
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
59c009776dae5ccbdfb93d7151ff2065ca049dc3 |
|
30-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Introduce multiple displays with DisplayContent. Fix a couple of bugs that turned up. Remove touch/focus from display. Add iterators for access. Respond to comments. Remove TODOs, and some deviceId parameters. Change-Id: Idcdb4f1979aa7b14634d450fd0333d6eff26994d
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
f35fe23669aeeebd2db2acb6baacae503dba03a8 |
|
02-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Add new OOM adjustment for the "previous" process. This is the process that you had previously been interacting with in the UI before the current one. Treating it specially should allow us to improve the scenario of switching back and forth between two apps. Also add API constent for ICS MR1. Change-Id: Ib3fe4df36b270be11dfd6b7e8d107c9994058a4d
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
e02c88af7935c72fb90a478375e61e4a94465587 |
|
28-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Work on process management. Introduce a new concept of "B" services. All running services are classified as either A or B. B services are later in the LRU list. Their oom_adj is after the home app. This allows us to better pick services to kill based on how long they have running, and should reduce the amount that we end up killing the home app. This temporarly turns on a debug log when the oom_adj of a process is changed. Sorry, I know it is noisy. This is needed to try to track down why some processes are being killed. Also add a flag to the SyncManager's service binding to allow the syncing process to be more aggressively killed if it has done UI. This is to address cases we have seen where sync is causing an 80MB gmail process to be kept around, preventing other process from running. Now what will happen is that the syncing process will aggressively be killed by the system, and can then be restarted in a much lighter-weight state. Do a little tweak in the power manager to allow us to still do smooth brightness changes even when the fancy TV off animation is in use. And get rid of a debug log in the window manager that was accidentally left in. Change-Id: I64a8eeaaa1f096bab29c665fbff804c7f1d029e2
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
295e3c27e4e3762a002382fc1657f5f0070a3410 |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5214105 and work on issue #5109947. Change-Id: Iff2cfec5280a314989d915aa830c16124f921611 5214105: taking a screenshot while "Android is upgrading..." crashes device 5109947: Race condition between retrieving a content provider and updating its oom adj
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|
7d608423b721e0153f37bfd5eba78fcd2489562d |
|
08-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Move OOM kernel settings to activity manager. The activity manager now take care of plugging the correct settings into the OOM killer in the kernel. This is a lot cleaner because it is really central to how the activity manager works, and nobody else cares about them. Taking advantage of this, the activity manager computes what it thinks are appropriate OOM levels based on the RAM and display size of the device. Also a small optization to the package manager to keep a binding to the package install helper for a bit after done using it, to avoid thrashing on it. And some new APIs that are now needed by Settings. Change-Id: I2b2d379194445d8305bde331c19bde91c8f24751
/frameworks/base/services/java/com/android/server/am/ProcessList.java
|