天天看點

Lost RAM可能的原因

最近遇到一個Lost RAM占用記憶體達到1,296,701K,Free RAM隻有157,924K 出現lowmom問題:

MemInfo:    43,292K slab,   114,292K shmem,    65,292K vm alloc,    12,324K page tables     5,568K kernel stack
               1,572K buffers,   269,472K cached,   188,532K mapped,    75,412K free
  ZRAM:         4K RAM,   520,908K swap total,   520,908K swap free
  Free RAM:   157,924K
  Used RAM:   591,439K
  Lost RAM: 1,296,701K
           

可以看到,出現lowmom問題是,Used RAM并不高,和正常的相差無幾。

發現問題出現時,Lost RAM異常的大。

查閱相關資料,發現Lost RAM可能來自下面幾個方面:

ION:我們知道很多多媒體的應用使用ION來配置設定memory的.大多數晶片供應商是沒有把這部分Memory map到process中,也就沒有統計在cached中.而ION為了配置設定效率會把這部分用過的memory先cached以便下次使用的時候直接從cache中配置設定,進而加快了配置設定速度,提高了系統性能.而當系統的memory吃緊時,這部分cached memory會free.這往往是Lost RAM的主要來源。MTK上就有類似問題導緻Lost RAM越來越大的問題,最後都是通過patch解決的。

KGSL:Graphic系統配置設定的記憶體.這邊分記憶體可能已經map到了process中,也有可能沒有map到process中,取決于晶片廠商的實作.如果沒有map到process ,這也是Lost RAM的重要來源。

ZRAM:ZRAM中被用掉的部分。

統計方法差異:多次計算用過的memory,例如filecache ,DSS等.常見的Lost RAM為負數就是這個原因。

未完,待續。。。