Hi all gem5 users,
A while back, I had contacted the SPEC committee to ask what their
stance was about sharing gem5 SPEC CPU checkpoints (I am not aware of
any public repo of gem5 checkpoints but I might be wrong!)
tl;dr : checkpoints can be shared as long as it is behind a password,
and the password is only given to people who have a SPEC CPU 2kX license
(this can be verified by emailingi...@spec.org <mailto:i...@spec.org>)
This is the exact answer that I got (I am quoting verbatim) :
1. The checkpoints distributed shall not contain enough code to produce
a compliant SPEC CPU 2017 run.
2. The whole checkpoint process must follow the Fair Use rules for
Academic/research usage: https://www.spec.org/fairuse.html#Academic
3. Arthur and his team [or a volunteer] shall maintain the checkpoints
and let the SPEC CPU committee know of the location which they will be
hosted from.
a. The SPEC CPU committee shall also be given ability to check on
checkpoints hosted and shared.
b. The link shall be protected by a password or similar
authentication method such that anyone that has the link to the location
cannot automatically download data which may contain SPEC CPU 2017 code
and/or executables.
4. The person/entity receiving the checkpoint may not distribute it
beyond themselves and/or beyond the scope of the immediate need for the
checkpoint.
I wanted to start a discussion about whether there is interest in doing
this (not only for SPEC, but SPEC is a big one).
On the one hand, checkpoint format has been changing often and so
checkpoint occasionally break. Moreover, certain features may require
generating new checkpoints anyway (adding model specific registers maybe?).
On the other hand, since many researchers generate their own
checkpoints/simpoints, there is a lot of variability (maybe a given
mechanism is not that interesting if I compile with O3 but works great
with O2), and having some "golden" checkpoints for usual workloads may
help homogenize gem5 research. Since gem5 has releases, maybe tying
"golden" checkpoints to releaseswould be a good enough workflow for many
users.
Cheers,
Arthur
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
