A proof-of-concept implementation that tracks the calls to the mmap() family is in [2]. It waits for a signal to writes anonymous memory to files and maps them back so that the non-varying parts can be evicted and those rarely used data can be swapped out.
In the test[1], it saved about 17MB out of 46MB anonymous memory on average without manually calling GC, or 10MB out of 38MB right after GC. The size of the varying parts (measured by summing Private_Dirty pages) is quite stable and is around 22MB. The non-varying working set (Private_Clean) is around 4MB ~ 7MB. In some extreme cases, such as running SunSpider 1.0, the Rss(committed physical memory) of browser went to ~130MB and ~100MB before killed with and without this patch, respectively. Namely, it gets extra 30MB memory at the expense of performance. The downside of this patch is that it cost about 5 sec to write out all anonymous memory that is tracked. This would incur a non-acceptable freeze of the device, including UI. A possible way to ease the lag is write out the memory incrementally; It will be implemented in the next WIP patch. The impacts to the performance other than the above are complicated and still under evaluation; Since the data are written out, the tests will include both cold-cache and warm-cache cases. [1] open twitter, facebook and look around. [2] https://bugzilla.mozilla.org/show_bug.cgi?id=899493 ----- Original Message ----- From: "Justin Lebar" <[email protected]> To: "Ting-Yuan Huang" <[email protected]> Cc: "Thinker Lee" <[email protected]>, [email protected] Sent: Thursday, July 4, 2013 1:23:08 AM Subject: Re: [b2g] Some observations on memory usages in main process It's interesting to know that about 30mb of memory is not written to often, but that's only half the story. The other half is, how often are those pages read? If they're read often, there's little we can do from the OS level. My guess would be that there's plenty of memory that's not read very often, but who knows! On Jul 3, 2013 3:49 AM, "Ting-Yuan Huang" <[email protected]> wrote: > Hi, > > We recently observed that > > 1. About half of the anonymous memory in b2g do not vary very often. > We taked a snapshot after booting into lock-screen. After playing for > a while[1], we taked the other > snapshot. The common parts of the two snapshot are around 30MB out of > total 60MB anonymous memory. > > 2. We tried to compress the anonymous memory in b2g and the compression > ratio is 25% ~ 50%, depending on > the compression methods. > > It seems that we can take advantage of these characteristics. For 1, we > might either > > a. Write those anonymous memory into files and map them back after > booting so that they can be used as > page caches and OS can evict them on memory pressure. > b. Intercept mmap() to redirect all mmap(..., MAP_ANONYMOUS, ...) into > files. This is very similar to a. > c. Enable swap. > > They all rely on that Linux kernel evicts clean pages first and then dirty > pages. We must tune > some parameters to strike a balance among performance, memory usage and > the life of flash. > > For 2, we might enable in-kernel memory compressions[2]. For example, zRam > is an in-memory swap device that > pages are swapped in/out before/after decompression/compression, > respectively. There's no write to flash. > We might in addition add some APIs to hint kernel. For example, when an > application is lowered to > background, it is expected to be less active and becomes a good candidate > to be compressed and swapped out. > > What do you think? > > [1] Open facebook and twitter and look around, take a picture, run > sunspider and so on. > [2] http://lwn.net/Articles/545244/ > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
