Re: Thinking aloud.

Hi Ted.

On 10/22/2012 01:27 PM, Theodore Ts'o wrote:
> On Sat, Oct 20, 2012 at 08:20:28AM +1100, Nigel Cunningham wrote:
>> My initial thought is to use SHA1 checksums to determine what pages
>> have changed, keeping those checksums (and the pfns to which they
>> refer) in memory or on disk between hibernation cycles.
> Hi Nigel,
>
> One thought --- if you are on a 64-bit machine, where we don't have a
> shortage of page flags, you could set a new flag on all pages that
> were saved during the last hibernate cycle, and on the restore, mark
> all pages in the page table read/only.  As the pages get modified, on
> the page fault, clear the flag.  This should be a lot faster than
> burning the memory bandwidth and computational resources needed to
> calculate SHA1 checksums on all memory pages which are in use.
>
> If you can't do this approach, something else that would probably
> worth doing is using a two-pass checksum; first use a very fast
> checksum, such as Adler-32 or Fletcher-32, which is memory bandwidth
> limited.  If the fast-but-not-entirely checksum doesn't match, there's
> no point trying to doing the (much slower) SHA1 checksum over the
> page; you'll know that the page has changed.  If the fast checksum
> matches, then you can do a second pass with SHA1 to make sure you can
> really skip doing the disk write.
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?

I like the page flags idea... I'll look into it some more. Would it work 
on non-x86?

Nigel