Hi Salil,
If I understand your question correctly you are asking why execute a
block of code before retrying the transaction?
Heres a scenario which I know requires the retry-code. If during the
transaction you miss during a TLB lookup then the transaction is aborted
because translations are not allowed inside a rock transaction (there
are quite a few things not allowed inside rock transactions). If you
were to naively restart the transaction at this point, rolling back to a
checkpoint, then the same thing would happen (because the translation
has not yet occurred and so another lookup results again in a miss).
This would happen ad infinitum (or until the OS kicks the process out
whichever is first :) )
If however inside the retry-code you check for such an error using the
status register, then you can prevent retrying and perhaps do something
to overcome the obstacle.
Does the make sense, perhaps Dan or someone who is more familiar with
the exact mechanism can give you a better answer.
Regards,
Matt
salil pant wrote:
I am a little confused about the retry hack being used in the ATMTP/Rock
simulator.
This is what I have understood so far :- you catch exceptions within
Transactions and detect their type.
Inside the Core_Exception hap, however, you change the PC to point to a
new location which contains the RETRY instruction.
What does this do? Does the code inside the exception handler execute or
not ?
what is the use of the retry ? I ask this mainly because we abort
when the exception completes anyway and we change the PC back to the
beginning of the transaction.
Why not just let the execution handler finish and then simply rollback
using a checkpoint and switch the PC back to the start of the transaction ?
What am I missing here ?
salil
On Thu, Jul 24, 2008 at 7:03 PM, salil pant <floydian27@xxxxxxxxx
<mailto:floydian27@xxxxxxxxx>> wrote:
Hi, I have been using the LogTM system in GEMS ( 1.2 ) . I have been
working on implementing some extra features for transactional
memory, but I keep running into exceptions within transactions that
"hang" my system. The processor starts taking a lot of window
spill/fill exceptions and then is not able to get out of the
transaction.
Using SIM_get_exception_name I was able to get the type of
exception that starts the problem - fast_data_access_mmu_miss. This
seems to be a dtlb miss exception.
I followed some of the techniques in the previous posts , namely
warming up the TSB/ TLB by running the benchmark once in SIMICS
without RUBY installed or touching the data structure before the
transaction. This has not helped me so far.
I guess my question is - Are there any more solutions to avoid
getting tlb miss exceptions within transactions ?
Can we run transactions from benchmark suites like Splash/STAMP ,
which can be really long and can take tlb exceptions, without
crashing ?
Do the later versions of GEMS have a solution for this ? I have
been reading some of the SimicsHypervisor code in the latest
versions and that seems to include callbacks to detect tlb misses.
Have the callbacks been implemented to tackle this issue ? and is
that the only thing needed if I were to use them in my version ?
thanks
salil
------------------------------------------------------------------------
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
--
Dr. Matt Horsnell - Research Associate, APT Group
Room 412, IT Building, School of Computer Science
University of Manchester, Manchester, UK. M13 9PL
Phone: +44 (0)161 275 7274 <http://www.cs.man.ac.uk/apt/>
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}