Thank you for the feedback, Giacomo.
That sounds reasonable, although a year sounds a bit short. Personally, I use 10 cores to create checkpoints, therefore (assuming that once the Simpoints are taken, there is no need to take them again): (~20 SPEC benchmarks / num cores) * 30 days = 2 months to create all checkpoints. Some people use more benchmarks, compare architectures (thus 2x/3x benchmarks), or have less available cores, so it might make sense to think that this process may take half a year or more. Anyway, even if the user does not update the checkpoints within the time frame Git history will help them conduct their experiments a little longer by providing old upgraders. If other devs agree on this, I could take a look at what needs to be done on the verifier to warn the user when they have potentially changed checkpoints. A CI that creates a short checkpoint (10 instructions, doesn't matter) and tries to restore from it would be an interesting addition if Jason figures out how to add CI to Gerrit. Regards, Daniel Em sexta-feira, 22 de fevereiro de 2019 16:24:48 GMT+1, Giacomo Travaglini <[email protected]> escreveu: #yiv3098383984 P {margin-top:0;margin-bottom:0;}Hi Daniel, Supporting old checkpoint is something nice but has the cost of having to update util/cpt_upgrader.py for every sensible addition.The end result as you are saying will be a gigantic, overpopulated cpt_upgrader patcher. What about defining checkpoint history windows: we support restoring checkpointsonly if they are not older than the time frame. In this way we can flush the cpt_upgrader at the end of eachwindow (could it be something like 1 year time?) Let me know what do you think about this. regards Giacomo From: gem5-dev <[email protected]> on behalf of Daniel Carvalho <[email protected]> Sent: 20 February 2019 11:35 To: Gem5 Developer List Subject: [gem5-dev] Checkpoint upgrader Hello, all. Recently I discovered the util/cpt_upgrader.py, a tool that relies on the existence of upgraders, which should be added for every modification of checkpoints. Was it something that indeed worked? The last upgrader was added 2 years ago; is there a specific reason why support for what seems to be a very handy program has been dropped? One thing we could do to mitigate future lack of upgraders would be to create a verifier that warns the user when a SERIALIZE/UNSERIALIZE is added/removed, and a respective upgrader isn't added. This, however, will likely overpopulate the cpt_upgraders. Regards,Daniel _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-devIMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
