Even those pages are read often, we can still create a private map for a back file. With a private map, since they are rarely written, the kernel can claim those clean pages very soon (no paging out) when we are with memory pressure. The key is how quick the pages are paging in again.
We can check access flag of page table entries to get the frequency of page reading. Justin Lebar <justin.le...@gmail.com> writes: > 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" <thu...@mozilla.com> 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 >> dev-b2g@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-b2g >> -- Sinker -- 天教懶漫帶疏狂 _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
