[CRIU] [PATCH 1/2] pagemap: Introduce pagemap cache

[Cyrill Gorcunov]

On Wed, Feb 12, 2014 at 01:15:02AM +0400, Andrew Vagin wrote:
> > +
> > +		/*
> > +		 * Gap is too big, can't continue.
> > +		 */
> > +		if (size_gap > size_cov) {
> 
> I don't like this condition.
> Let's imagine that we have:
> * big vma (50Mb)
> * two small vma (20Mb) and the hole (10Mb) between them
> 
> |___50Mb___|  |_20Gb_| 10Mb |_20Gb_|
> 
> According to this condition the hole will be in cache.
> 
> I think useing cache will be slower in this case.
> 
> Maybe the size of hole should be limited...

Yes, the problem is how to determine which hole size is acceptable.
Read speed depends on many factors, what would be faster -- read
two chunks of 20M or one chunk of 30M (and kernel handles holes
faster than present pages). I guess we migh need to gather some
statistics here.

Same time, imagine

| 50p | 2h | 1p | 2h | 1p | 2h | 1p | 2h | ..

where p -- present, h -- hole (and assume we choose 2M as hole
limit) -- this breaks the whole idea of cachhe because it become
throttling, every present area followed by trigger-size hole which
force cache to read every vma as cold.

I think some scenarios are unavoidable (until we implement more
complex logic, which I tried to escape).