Re: Thinking aloud.

Nigel Cunningham <[email protected]> Fri, 26 Oct 2012 07:51:50 +1100
Newsgroups gmane.linux.swsusp.devel
Message-ID <[email protected]>
Hi.

On 10/26/2012 03:06 AM, Theodore Ts'o wrote:
> On Thu, Oct 25, 2012 at 08:32:10PM +1100, Nigel Cunningham wrote:
>> I started some work on this today, and it occurred to me (wrongly?)
>> that if I go down the Fletcher-32 path, it's pointless. If the
>> Fletcher-32 checksums match, I have to do the SHA1 to check the
>> pages really are the same. If they don't match, I still have to
>> calculate the SHA1 of the new contents so I can store it. So I may
>> as well just calculate the SHA1 for every page and compare them. Am
>> I making a mistake somewhere?
> Hmm, good point.  I forgot that in the case where they don't match,
> you need to calculate the SHA1 for the next suspend/resume cycle.
Taking it one step further, would you agree with the assertions of 
others that even if the SHA1s match, I still need to memcmp the pages to 
check they're actually the same (so SHA1 is effectively reducing an 
O(n^2) comparison of pages with each other to O(n)).
> I like the page flags idea... I'll look into it some more. Would it
> work on non-x86?
> It should.  As long as the VM supports read-only pages (which is
> pretty much all of the major ones, since you can't have any kind of
> security if you don't --- imagine what might happen if a bad guy can
> modify the text page of the shared libc image, for example).
Cool. Makes perfect sense; I guess I misunderstood something I read on 
LKML long ago and now can't remember :) Okay; I'll give that a go then, 
particularly having seen the cost of calculating the SHA1 for every page.

Following on the other thread a bit longer, MD5 was faster (429MB/s) 
than SHA1 (320MB/s). It would be interesting to see whether the 
increased speed of MD5 results in a significantly greater number of 
pages that are false positives.

Regards,

Nigel