6

As I have mentioned in question, Lost RAM appears in Dumpsys meminfo.

  1. What is the concept behind “Lost RAM” which appears in Dumpsys meminfo?
  2. What is its significance in Kitkat. How it can be reclaimed and used?

Sample dumpsys showing "Lost RAM".

Total RAM: 998096 kB
 Free RAM: 574945 kB (145869 cached pss + 393200 cached + 35876 free)

 Used RAM: 392334 kB (240642 used pss + 107196 buffers + 3856 shmem + 40640 slab)

 Lost RAM: 30817 kB

   Tuning: 64 (large 384), oom 122880 kB, restore limit 40960 kB (high-end-gfx)
Paresh Mayani
  • 127,700
  • 71
  • 241
  • 295
user3328095
  • 61
  • 1
  • 2
  • It's `lost = total - lost - free`, i.e. it's the stuff that the accounting mechanism didn't manage to account for. I don't know if "lost" is the right word, but dumpsys meminfo can't figure out what it's being used for. – fadden Feb 20 '14 at 02:05

2 Answers2

5

On my system, they are caused mostly by ION (which replaces pmem). If ion debug is enabled with your kernel, you can calculate your ION usage with this script:

adb shell cat /d/ion/heaps/system|perl -ne 'chomp; if (m/pages in.*pool = (\d+) total/) {$x += $1;} if (m/^\s+total\s+(\d+)$/) {$y += $1} END {printf "use: %d kb, cache: %d kb; total: %d kb", $y/1024, $x/1024, ($x + $y)/1024}'

In fact, any kernel page allocation done and tracked by drivers will not be tracked by the kernel, thus counting for the lost ram.

After I stop the system server, I used another .awk script to calculate lost ram (dumpsys meminfo will require the meminfo service and thus won't work anymore), and the lost ram is very closely following ION debug output: 

#!/usr/bin/awk

BEGIN {
    types["MemTotal"] = 1;
    types["Pss"] = 1;
    types["MemFree"] = 1;
    types["Cached"] = 1;
    types["Buffers"] = 1;
    types["Shmem"] = 1;
    types["Slab"] = 1;
}


## start code-generator "^\\s *#"
#echo
# for x in Pss MemTotal MemFree Cached Buffers Shmem Slab; do
#     cat << EOF
#/$x: / {
#     hash["$x"] += \$2;
# next
#}
#
#EOF
# done
## end code-generator
## start generated code

/Pss: / {
    hash["Pss"] += $2;
    next
 }

 /MemTotal: / {
     hash["MemTotal"] += $2;
     next
 }

 /MemFree: / {
     hash["MemFree"] += $2;
     next
 }

 /Cached: / {
     hash["Cached"] += $2;
     next
 }

 /Buffers: / {
     hash["Buffers"] += $2;
     next
 }

 /Shmem: / {
     hash["Shmem"] += $2;
     next
 }

 /Slab: / {
     hash["Slab"] += $2;
     next
 }


## end generated code

END {
    lost =  0;
    for (type in types) {
        if (type == "MemTotal") {
            lost += hash[type];
        } else {
            lost -= hash[type];
        }
    }
    print "lost: " lost " kB\n";
}

I also checked again after I force a kernel memory shrink with adb shell sh -c 'echo 3 > /proc/sys/vm/drop_caches', the results are still very close.

Bao Haojun
  • 966
  • 5
  • 9
  • 1
    Here's how to use the .awk script: `adb shell sh -c 'busybox awk -f /system/bin/check-meminfo.awk /proc/*/smaps /proc/meminfo'`. Note you may need to tweak the quoting, my adb has got the quoting fixed so that `adb shell sh -c 'echo "hello world"'` will work as expected. – Bao Haojun Apr 01 '14 at 04:43
0

Firstly, it is not an accurate value, and executing the dump is time-consuming, which can lead to a decrease in computational accuracy. In addition, possible reasons include socket stacking, using some unregulated memory application method to apply for memory, and graphic related memory applications.

CachedPss is usually 0 lostRamResult = MemTotal -（Used RAM + Free RAM）+ totalSwapPss - memInfo.getZramTotalSizeKb()

Stang
  • 1