The 20MB isn't, the pages_shared is, i meant pages_sharing .. oops :) Guillaume
On 05/17/2013 04:35 AM, Ting-Yuan Huang wrote: >> Paged saved counted in /sys/kernel/mm/ksm/pages_shared > > If the 20MB saved is based on the above which is not a typo, it could > actually be even better: > > In Documents/vm/ksm.txt: > pages_shared - how many shared pages are being used > pages_sharing - how many more sites are sharing them i.e. how much saved > > Since pages_sharing >= pages_shared. > > ----- Original Message ----- > From: "Guillaume Destuynder" <gdestuyn...@mozilla.com> > To: dev-b2g@lists.mozilla.org > Sent: Friday, May 17, 2013 7:55:36 AM > Subject: Re: [b2g] Introduce COW for B2G > > Out of curiousity I tried KSM on the current B2G and I had some memory > savings (about 20megs saved with a few apps running) > > Your arguments are 100% valid however. > I've also tested pksm, which seems to do something in between, hooking > the mmap calls and not scanning memory (http://code.google.com/p/pksm/) > > The KSM scan does not seems to impact perf from a very non-scientific > measurement (top ;-) > > If you're curious, here's the code: > > https://github.com/gdestuynder/releases-mozilla-central/commit/edd4c7d638639a6200703560f885f5c249aee2fb > > Need KSM enabled in kernel as well, then: > adb shell echo 1 > /sys/kernel/mm/ksm/run > Scanning happens every 20ms which is pretty often actually, but can be > set to anything. Long timers will actually use more CPU as there is more > to do in one run. > > Paged saved counted in /sys/kernel/mm/ksm/pages_shared > > Finally, I think it would be interesting to have something like memcow > in mainline, specially so that desktop can use it as well if they go > multiprocess. > > Guillaume > > On 05/04/2013 01:51 AM, Thinker K.F. Li wrote: >> KSM is with higher overhead on scanning equivalent pages with MAC. >> Memcow does not scan since the userspace requests COWs directly. >> >> KSM is working in async fashion that can not treat memory burst in a >> very short time. >> Memcow applys COW immediately once the userspace makes a request. >> >> KSM will scan all dirty pages with madvised periodically. >> Memcow never do that. >> > t >> Guillaume Destuynder <gdestuyn...@mozilla.com> writes: >> >>> Out of curiosity, is the end result very different from KSM? (as in >>> Kernel SamePage Merging) >>> >>> While I'm no expert with this, KSM scans for memory areas selected in >>> userspace via madvise (madvise(addr, size, MADV_MERGEABLE)) then >>> deduplicate it in a similar fashion and set the page as COW (it can also >>> rerun the deduplication several times AFAIR, so if more identical pages >>> are found overtime [that have been madvised] those would be dedup'd too) >>> >>> >>> Guillaume >>> >>> On 05/03/2013 12:57 AM, Thinker K.F. Li wrote: >>>> In bug 850175 and previous discussion at this list, we learnt memory >>>> duplications eating out devices memory in some cases. Ting-Yuan had >>>> mentioned about KSM that can merge pages with same content to avoid >>>> duplication. But, it takes CPU times and is not reliable while it can >>>> not merge pages in time/immediately during memory peaks. So, to >>>> trigger it for OOM can not solve our issues. >>>> >>>> After some discussions, Ting-Yuan is trying to implement a COW >>>> mechanism at userspace for sharing pages of source and target memory >>>> blocks passed to memcpy. He expect to use a memdup() function to >>>> replace all malloc() & memcpy() paired function calls. So, we do some >>>> tricky magic to make COW applied. (I believe he will explain it >>>> later.) >>>> >>>> Last few days, I am working on a kernel module to implement COW; call >>>> it memcow. memcow provides a function that user space processes can >>>> map a block of annonymous memory block to another annonymous memory >>>> block, so they are sharing the same set of pages but COW; page aligned >>>> of course. In another word, you can use memcow to map pages of A >>>> block to the address range of B block, A and B are allocated through >>>> malloc(), instead of calling memcpy. It saves a lot of memory, >>>> especially for the cases like bug 850175. >>>> >>>> So, what do you think? >>>> >>>> - https://bitbucket.org/thinker/memcow >>>> _______________________________________________ >> > _______________________________________________ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
