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

Christopher Covington cov at codeaurora.org
Mon Apr 6 13:33:08 PDT 2015


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.

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.

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


More information about the CRIU mailing list