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

_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to