Date: | Sat, 2 Jun 2007 08:27:31 -0700 (PDT) |
---|---|
From: | James Wang <jameswang99@xxxxxxxxx> |
Subject: | Re: [Gems-users] LogTM Warning |
Hi :
I did some more work about the following warning: Warning: in fn void RegisterState::enableInterrupts(int) in log_tm/RegisterStateWindowed.C:336: "WARNING: in enable interrupts" is WARNING: in enable interrupts Warning: in fn void RegisterState::enableInterrupts(int) in log_tm/RegisterStateWindowed.C:337: pil is 0 and found out that these warning is caused by a trap exception. Currently, the LogTM RegisterStateWindowed object will disable the interrupts by setting the pil register to 15 at the beginning of a transaction. Then, when the transaction is about to commit, it checks if the pil register is still 15 and if it is not 15 the warning is printed onto the screen. There are some exceptions that have interrupt level 16 which is higher than the pil value 15 a transaction set to when the transaction begins, so that exception is handled by the OS. When that exception is finished, the OS sets the pil to 0. And now the transaction commits and checks the pil is not 15, and the warning is thrown. RegardsSo, if you are not sure about what happens in your benchmark, I suggest that you turn on the exception profile option in $GEMS/gen-script/microbench.py. This will provide information about what kind of exception has been taken during your benchmark's running time. And you could then try to identify whether there is any exception that has interrupt level higher than 15 to determine if you are on the right track. James ----- Original Message ---- From: Cong Wang <jameswang99@xxxxxxxxx> To: Gems Users <gems-users@xxxxxxxxxxx> Sent: Tuesday, May 22, 2007 7:24:23 AM Subject: Re: [Gems-users] LogTM Warning James: It is my understanding that Nacks in LogTM does not always result in abort.
LogTM aborts if the current transaction is NACKed by an older transaction and then the current transaction NACKs an older transaction, which means there is a possible deadlock situation. And I don't think the pil register has any connection with NACKing directly, therefore not connected with atomicit violation. If you want to know more about pil register setting, please look at the $GEMS/ruby/log_tm/RegisterWindow.C. To know more about the LogTM protocol and how NACKing works, please read the $GEMS/protocol/MOESI_SMP_LogTM_directory-cache.sm. I am not sure exactly what kind of problem that you are experiencing. But LogTM should be pretty stable in terms of atomicity. If you could give me more information about the exact atomicity violation, I might be able to suggest more precise place to look. Regards James Wang On 22/05/2007, at 4:25 AM, James Poe wrote: Hi James, _______________________________________________ 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. |
[← Prev in Thread] | Current Thread | [Next in Thread→] |
---|---|---|
|
Previous by Date: | [Gems-users] Question about some terminologies, Ju-Young Jung |
---|---|
Next by Date: | Re: [Gems-users] LogTM Warning, James Poe |
Previous by Thread: | Re: [Gems-users] Identifying outstanding transaction, Juyoung Jung |
Next by Thread: | Re: [Gems-users] LogTM Warning, James Poe |
Indexes: | [Date] [Thread] |