[CRIU] [PATCH] Add test case for code page sharing

[Andrew Vagin]

On Mon, Apr 06, 2015 at 04:33:08PM -0400, Christopher Covington wrote:
> Hi Andrew,
> 
> On 04/02/2015 04:30 PM, Andrey Wagin wrote:
> > 2015-03-31 20:51 GMT+03:00 Christopher Covington <cov at codeaurora.org>:
> >> We've observed at least one scenario where processes originally
> >> sharing physical memory no longer do so after dump and restore.
> >> This increases memory usage and degrades performance. Here is a
> >> test case (created outside of the ZDTM framework for expedience)
> >> that demonstrates the issue. The test fails with CRIU 1.4. Run
> >> `make && ./test_sharing.sh` to build and run the test.
> > 
> > I've found a root cause of this problem. CRIU modifies code to inject
> > a parasite:
> > https://github.com/xemul/criu/blob/master/parasite-syscall.c#L219
> > 
> > So we affects only one page in a process. Is this really so critical?
> 
> I think this is a different reason for pages to not be shared. Ptrace parasite
> injection affecting the sharing of just one page is a problem that it would be
> nice to fix, but I agree that it's not that critical.

You test detects this page. I've changed your test to check main +
getpagesize() and it works fine.

> 
> But what we have observed isn't just one page but every page mapping the text
> sections of an executable. Please correct me if I'm wrong, but CRIU never
> restores text sections from the actual executable, but instead uses the image
> file. So the text sections will never be shared, except in simple parent-child
> relationships that are handled specially.

text section is an anonymous file mapping. In such cases CRIU maps the file
and restore only changed pages.

static inline bool should_dump_page(VmaEntry *vmae, u64 pme)
{
...
        /*
         * Optimisation for private mapping pages, that haven't
         * yet being COW-ed
         */
        if (vma_entry_is(vmae, VMA_FILE_PRIVATE) && (pme & PME_FILE))
                return false;

Thanks,
Andrew

> 
> If we wanted to go about fixing either of the above issues, do you have any
> guidance?
> 
> For example, would it be possible to extend the hole-punching/de-duplication
> mechanism to remove text pages that have been verified to match an ELF file? I
> don't know if a documented order (first search image files, second search ELF
> files) or some kind of table in the image files (for this address, look in
> images, for that address look in ELFs) or command line switches would be best
> to control the search behavior.
> 
> Thanks,
> Chris
> 
> -- 
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project