ruby: recorder: Fix (de-)serializing with different cache block-sizes

Information
Submitter:	Marco Elver
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

ruby: recorder: Fix (de-)serializing with different cache block-sizes

Upon aggregating records, serialize system's cache-block size, as the
cache-block size can be different when restoring from a checkpoint. This way,
we can correctly read all records when restoring from a checkpoints, even if
the cache-block size is different.

Note, that it is only possible to restore from a checkpoint if the
desired cache-block size is smaller or equal to the cache-block size
when the checkpoint was taken; we can split one larger request into
multiple small ones, but it is not reliable to do the opposite.

Testing Done

Created a Ruby checkpoint with the default config. Restore from checkpoint with default config (64 byte block-size) and varying block-sizes (32, 16, 8).

You should update the gem5 checkpoint version and add functionality to the
util/cpt_upgrader.py script for updating checkpoints affected by your changes.

Change Summary:

Applied suggested changes. This change no longer breaks old checkpoints, but having the correct block-size serialized in the checkpoint will not cause surprises when changing the block-size; I assume the user will be aware of potential issues when they see the unmissable outdated-checkpoint warning.

Tested again: migrating old checkpoint, take checkpoint, restore checkpoint.

Description:

		ruby: recorder: Fix (de-)serializing with different cache block-sizes

~		Upon aggregating records, serialize the system's cache-block size (add
~		to beginning of byte stream), as the cache-block size can be different
~		when restoring from a checkpoint. This way, we can correctly read all
~		records when restoring from a checkpoints, even if the cache-block size
	~	Upon aggregating records, serialize system's cache-block size, as the
	~	cache-block size can be different when restoring from a checkpoint. This way,
	~	we can correctly read all records when restoring from a checkpoints, even if
	~	the cache-block size is different.
-		is different.

		Note, that it is only possible to restore from a checkpoint if the
		desired cache-block size is smaller or equal to the cache-block size
		when the checkpoint was taken; we can split one larger request into
		multiple small ones, but it is not reliable to do the opposite.
-
-		This patch breaks existing ruby checkpoints. It is possible to fix
-		them by modifying system.ruby.cache.gz and prepend the cache-block
-		size the checkpoints were taken with.

Diff:

Revision 2 (+73 -36)

Show changes

	src/mem/ruby/recorder/CacheRecorder.hh
	src/mem/ruby/recorder/CacheRecorder.cc
	src/mem/ruby/system/System.cc
	src/sim/serialize.hh
	util/cpt_upgrader.py

Ok, it now seems that we do not require this version and updates
to the utility script.  Since it is optional that the block size 
be unserialized, the earlier checkpoints will not break.  For 
those checkpoints, the current block size would be assumed to be 
the block size with which the checkpoint was created.  If you 
agree, then I suggest that you eliminate the not required code.

Marco Elver April 10, 2014, 12:20 p.m. (April 10, 2014, 12:20 p.m.)

The cpt_upgrader could be used to fix existing checkpoints to permit using old checkpoints with different cache-block sizes. I have already found this useful on many of my existing checkpoints.

I made unserializing the block-size optional, because reverting to the old behaviour does not require much code, but nevertheless is broken.

If this use case (use checkpoints with different block-size) is too rare to justify incrementing the checkpoint version, let me know and I can revert the version and cpt_upgrader.

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Change Summary:

Description:

Diff:

Status: Closed (submitted)