With memcow, checking size and alignment for source and targeet in memcpy() is most simple one of here purposed ways to apply COW. A wrapper for memcpy may be enough.
From: Ting-Yuan Huang <[email protected]> Subject: Re: Introduce COW for B2G Date: Fri, 3 May 2013 03:04:11 -0700 (PDT) >> 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.) > > I'd like to propose a new API to jemalloc, called memdup(). memdup() behaves > similar to the standard strdup(), except that it duplicates memory instead > of null-terminated strings. It's quite often that a memcpy() immediately > follows an malloc() and the contents in source and destination then are > identical. In this case we can point the virtual pages of the destination to > the > physical frames of the source and defer allocating and copying memory by > marking them copy-on-write. If there is a non-trivial ratio of pages not > altered eventually, memory and CPU usages are saved. > >> 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. > > Getting anonymous pages by mmap() and immediately calling memcow() is > equivalent to memdup() which is semantically better I think :) > > Another possible approach might be, as an optimization, to implement COW in > memcpy(). One of the difficulty could be how to identify safe sources and > destinations. > > Any ideas? _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
