[CRIU] dedup and memory tracking

Pavel Emelyanov xemul at parallels.com
Wed Jun 11 04:46:40 PDT 2014


On 06/11/2014 03:37 PM, J F wrote:
> I've been playing around with:
> 
> http://criu.org/Memory_changes_tracking
> http://criu.org/Incremental_dumps
> 
> For my application (a Java app), a second incremental dump after several seconds with 
> auto dedup still results in a pretty big image page for the second dump, over 4 megs,
> even if I don't change perform any interaction with my application.
> 
> With any Java app, I'm sure there are background tasks occurring that can change memory
> even without my explicit interaction, but I was still surprised by the large image page
> size for an incremental dump with dedup enabled.
> 
> I'm running ubuntu 14.04 with kernel 3.15 RC 6.
> 
> Before I investigate more, I am curious if this is expected and/or any thoughts. 

Provided you use the --track-mem and --prev-images options, the behavior is
not expected to be like this. BTW, there was a bug on the 'Incremental dump'
page -- the --track-mem option should be used always.

Do you have memory tracker compiled in the kenrel? The "criu check" option
can check this, what does it tell?

Thanks,
Pavel


More information about the CRIU mailing list