I am not sure for now since it depends on how often of reclaiming clean pages and how often of paging in again. We shall do more experiments about memory read, and I have already some ideas of experiments. I guess it would be soon to get the report of reading.
James Ho <[email protected]> writes: > It sounds awesome! > > Do we have any idea about the overhead of this mechanism in terms of time? > > -- > James > > On Jul 3, 2013, at 7:16 PM, [email protected] (Thinker K.F. Li) wrote: > >> Thanks Ting-Yuan for spending time on investigation of memory >> modifications. The basic idea behind tasks is to figure out how many >> data are not modified after built. If we write these data out to the >> filesystem after boot, and use the file as a back object of anonymous >> memory pages, then we can get more free memory from clear pages if we >> need. >> >> For very lucky, Ting-Yuan find there are a big number of pages that keep >> not changed since they are built. So, we have a big chance to save a >> lot of memory. >> >> Ting-Yuan Huang <[email protected]> writes: >> >>> 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/ >> >> -- >> Sinker >> -- >> 天教懶漫帶疏狂 >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g > -- Sinker -- 天教懶漫帶疏狂 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
