On 03/04/11 14:58, Steve Reinhardt wrote: > The issue here is that we have a significant number of existing checkpoints > for large systems that would be prohibitively expensive to regenerate. If > it would work to just have the unserialize code default the value to 0 if > it's missing, that would be great. It sounds like you are saying that, but > could you confirm?
Defaulting it to zero would momentarily reintroduce the bug that this fixed, but then because it -is- fixed, after a brief stutter things would get back on track and should work as expected. It -should- be safe and only cause a small disturbance. I really have no way to concretely verify that, but nothing is coming to mind that would make that not true. > If not, a solution that involves scriptable updates to checkpoint files is > OK but not great. It wouldn't be a bad idea to explicitly add a size=0 to the checkpoints, but this would be equivalent to the defaults anyway. A more accurate value would be difficult to get without a non-trivial amount of work. > In general, we need to be much more cautious about updates that break > existing checkpoints. This fixed a bug that deadlocked O3 into infinite mispredicts in certain circumstances that should, by coincidence, only happen in FS, so it was an unavoidable change. Caution was not a factor. The change I'm going to need to make to break false condition code dependencies will also likely break existing checkpoints because it will change the register layout. This is also a necessary change if performance accuracy is important (and to many I think it is), although it might be easier to deal with with a script. The in flight state like renamed versions of registers would be painful to fix up, but architectural state would likely be pretty straightforward since bits would just move around. As I said last time this came up, I'll won't take breaking checkpoints lightly, but my primary goal is improving the code as it is today, not compatibility. If I need to fix a bug or have a change that significantly enhances functionality, I'm going choose to do that over keeping old checkpoints working. I understand the changes can be painful, but it would be a mistake to trap ourselves like that. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
