<div dir="ltr">Hi all,<div><br></div><div>thank you both for you help!</div><div><br></div><div>I ended up solving the problem with MADVISE_DONTNEED (which does not require changes to CRIU).</div><div><br></div><div>I did not need to use compel but it looks like a great tool and it gave me some ideas for future research :-)</div><div><br></div><div>Cheers,</div><div>rodrigo</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-05 8:45 GMT+00:00 Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@virtuozzo.com" target="_blank">xemul@virtuozzo.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/04/2016 08:20 PM, Raghavendra Prabhu wrote:<br>
> Hi,<br>
><br>
> I have seen similar problem manifesting in the form such as<br>
> <a href="https://bugs.launchpad.net/percona-server/+bug/1092645" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>percona-server/+bug/1092645</a> wherein people<br>
> don't want large memory pools in their coredumps. In this case, they<br>
> mark it as MADV_DONTDUMP. Is it good to assume that whatever is not<br>
> required in the coredump is not good for checkpoint images either. If<br>
> not MADV_DONTDUMP, /proc/$pid/coredump_filter is used.<br>
><br>
> So, wondering if something like<br>
> <a href="https://gist.github.com/ronin13/59c6ffab786db7ef9e54db4fb29b4992" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>ronin13/<wbr>59c6ffab786db7ef9e54db4fb29b49<wbr>92</a> would<br>
> be useful here.<br>
<br>
</span>I tend to agree, but ... from my perspective, pages that are not required<br>
in a core-dump might still be required for an application to work. So your<br>
patch is OK, but it required a CLI option to be turned on. Always silently<br>
dropping the MADV_DONTDUMP pages may cause problems.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Pavel<br>
</font></span><span class=""><br>
><br>
> On Wed, Nov 30, 2016 at 11:17 AM, Pavel Emelyanov <<a href="mailto:xemul@virtuozzo.com">xemul@virtuozzo.com</a>> wrote:<br>
>> On 11/30/2016 12:47 PM, Rodrigo Bruno wrote:<br>
>>> Hi all,<br>
>>><br>
>>> I am using CRIU to checkpoint JVMs with heaps > 10GB.<br>
>>><br>
>>> I want to reduce the size of the checkpoint and I know that there are memory ranges that<br>
>>> although being allocated and touched by the JVM, represent garbage and could be discarted<br>
>><br>
>> Heh... This is something I thought of long ago. The idea by that time was<br>
>> that we could ship a library that applications can link with, and, when<br>
>> criu dumps them, it can detect the library is there and call some code from<br>
>> victim task. So that application can do some preparatory work before being<br>
>> checkpointed. But this would require patching JVM :\<br>
>><br>
>>> when dumping the JVM (don't worry, I can ensure that the JVM is stopped while running this operation).<br>
>>><br>
>>> Q1. Does CRIU support this?<br>
>><br>
>> Nope :)<br>
>><br>
>>> Q2. Without changing CRIU, is there any way to achieve this? Could I change a page table<br>
>>> entry to force a page with garbage to be mapped to the zero page?<br>
>><br>
>> Yes and no. There are no standard knobs for this, but (!) we have announced<br>
>> compel recently. With it you can cook a parasite code that would call<br>
>> MADVISE_DONTNEED on the desired ranges thus punching the holes in memory.<br>
>><br>
>> -- Pavel<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> CRIU mailing list<br>
>> <a href="mailto:CRIU@openvz.org">CRIU@openvz.org</a><br>
>> <a href="https://lists.openvz.org/mailman/listinfo/criu" rel="noreferrer" target="_blank">https://lists.openvz.org/<wbr>mailman/listinfo/criu</a><br>
</span>> .<br>
><br>
<br>
</blockquote></div><br></div>