Hi Ritchie,
Polina is right, your simulation can't be hanged due to those operations.
Moreover, remember that GEMS "fakes" lazy version management, given
that it always uses the same "eager" coherence protocol to detect
conflicts --transactional modifications are never placed in the L1
cache during the transaction. However, OS "escape" memory accesses
still require the update of Simics memory (eager version management),
which may be a problem when executing lazy transactions. Hence, be
careful when transactions switch to PRIV_MODE, and be sure that these
operations are handled correctly.
For example, lazy transactions can't be aborted when they are executing
OS code. Notice that this situation never happens in eager HTM systems
because only user-mode memory accesses provoke conflicts. However, it
may happen in lazy HTMs that defer the resolution of conflicts until
commit time. In order to reduce the amount of OS operations, you should
use the memory allocation library provided in STAMP benchmark suite
instead of the conventional malloc library.
I hope that this helps,
--
Marc Lupon
Computer Architecture Department
Universitat Politecnica de Catalunya
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}