| 5e099800f83651d7b7acc02048e28e45f6986ea3 |
|
05-Oct-2017 |
Robert Benea <robenea@google.com> |
Incorporate slab reclaimable into meminfo
Instead of using the whole slab mem for kernel usage, split the
unreclaimable to kernel and reclaimable to cache (since is freed
under mem. pressure).
Test: tested on gobo
Bug:67753120
Change-Id: I0f5a310bb88603ad7bb28e5398ea57c249c04fc2
/frameworks/base/core/java/com/android/internal/util/MemInfoReader.java
|
| 6edb5c665dcb024ae7cfb95b9a92e30dcc5777c1 |
|
31-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Improve low on RAM reporting.
- Don't print every little native process.
- Print in different sections, so if one is too long we don't get the
rest truncated in the log.
- Include other info from meminfo -- ksm and free/used/lost summary.
Change-Id: Iea4ec3860212667e195d2b60b3ded23bfec78436
/frameworks/base/core/java/com/android/internal/util/MemInfoReader.java
|
| b3af4ec6bae4fe93d40f021e54cbbce10cc7b4c6 |
|
18-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17948288: Improve accuracy of memory use reporting
We now use Mapped to not double-count cached pages that are
mapped in to app processes. Also read in some more values that
count towards kernel RAM use, and count buffers as free rather
than used RAM.
It also looks like the zram accounting is broken -- it was never
collecting the total zram reserved space. I need to figure out
how I was finding that before.
Change-Id: I883f6fc93966774b5c7d2801d1801666dd11ed41
/frameworks/base/core/java/com/android/internal/util/MemInfoReader.java
|
| 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/core/java/com/android/internal/util/MemInfoReader.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/core/java/com/android/internal/util/MemInfoReader.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/core/java/com/android/internal/util/MemInfoReader.java
|