Re: [Gems-users] LogTM Warning

[Cong Wang <jameswang99@xxxxxxxxx>]

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,

Thanks for the response; that does make a lot of sense.  I was wondering what your opinion is as to how this changes the results of simulations?  It seems from my experience that when the pil register is reset, at least one memory operation is permitted that should otherwise continue to be NACKed (see the trace I posted previously).  Is this true, and if so, is this generally just written off as error?  Also, do you know if this will change the actual functional simulation since we may be allowing a memory transaction that violates the atomicity of the transaction?

Your insights are greatly appreciated,

James P

On 5/17/07, James Wang <jameswang99@xxxxxxxxx > wrote:

Hi James:

    From my understanding of the LogTM code, it seems that before a transaction starts it disables the processor's interrupt by setting the pil register to 15. But sometimes, the pil register gets reset by the system. And the warning message you got reflects that.
 

Regards
James

----- Original Message ----
From: James Poe < gemsmaillist@xxxxxxxxx>
To: gems-users@xxxxxxxxxxx
Sent: Thursday, May 17, 2007 4:04:10 AM
Subject: [Gems-users] LogTM Warning

I am working with the LogTM protocol and I was wondering if anyone could explain to me what this warning means:

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

I seem to run into it fairly frequently when I run simulations, and it seems to be followed by an inconsistency in the output trace.  An example of it occurring in the debug trace file shows:

8366153   3  XACT NACK 2 by proc: 2  ADDR [0x2c3ec580, line 0x2c3ec580]  PC [0xff312090, line 0xff312080]  my_ts 7201783  nack_ts 7189475
8366656   2  XACT STORE 2  ADDR [0x1218a9c0, line 0x1218a9c0]  PC [0x228a4, line 0x22880]
8366656   2  XACT COMMIT 2  PC 0x228a8
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
8366666   1  XACT NACK 2 by proc: 2  ADDR [0x2c3ec580, line 0x2c3ec580]  PC [0xff312090, line 0xff312080]  my_ts 7213054  nack_ts 7189475
8381469   3  XACT LOAD 2  ADDR [0x37456080, line 0x37456080]  PC [0xff312094, line 0xff312080]
8381479   3  XACT STORE 2  ADDR [0x2c3ec5bc, line 0x2c3ec580]  PC [0xff3120d4, line 0xff3120c0]


I believe this shows that CPU-3 is NACKed when accessing cache line 0x2c3ec580.  However, the warning message then appears and the next message we have concerning CPU-3 and T-2 is that it is LOADing a DIFFERENT cache line, 0x37456080.  The PC has also been incremented by 4.  To my knowledge, a NACK for an address must be followed by either a LOAD/STORE or ABORT for that address.  After the warning, however, it seems as though that access was just somehow skipped.  I don't notice this happening anywhere else, and I believe I have taken necessary precautions such as binding processes, etc.

Any help would be greatly appreciated,

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.

_______________________________________________
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.

_______________________________________________

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.