Re: [Gems-users] TLB MISS for Virtual Log Pointer

[Jayaram Bobba <bobba@xxxxxxxxxxx>]

Ruben

There is a dummy write in set_log_base in 
microbenchmarks/transactional/common/transaction.c
that is supposed to bring the address translation for m_logPointer into 
the TLB. Since this
dummy write is performed just before the magic call for setLogBase, the 
translation should
stick around in the TLB. The assert was added to check for the rare case 
where an intervening
exception (e.g., timer interrupt) might lead to TLB replacements. 
However, I dont think we have
ever run into this case before. If this is indeed the case, you might 
look into retrying the magic call
till it succeeds.

Jayaram

Rubén Titos wrote:
> Dear list,
>
> I'm trying to run some transactional microbenchmarks with Gems 2.1 and 
> simics 2.2.19. <http://2.2.19.> For runs with 2 and 4 processors the 
> benchmark runs just fine, but for 8 or more processors, I get an 
> assertion that makes the program fail when executing the setLogBase 
> function of log_tm/TransacionVersionManager.C
>        
> void TransactionVersionManager::setLogBase(int thread){
>   m_logPointer_physical[thread] = 
> Address(getDataTranslation(m_logPointer[thread].getAddress(), thread));
>   if(m_logPointer_physical[thread] == Address(0)){
>     if(XACT_DEBUG && XACT_DEBUG_LEVEL > 0) {
>       cout << proc_no << " TLB MISS for Virtual Log Pointer " << 
> m_logPointer[thread] << " thread = " << thread << endl;
>     }
>     assert(0);
>   }
>
> The data translation fails (tlb miss) for that address and a 0 is 
> returned, raising the assertion. The address to be translated does not 
> seem to be garbage:
> (gdb) print m_logPointer[thread]
> $1 = {m_address = 5148704}
> (gdb) print m_logBase[thread]
> $2 = {m_address = 5148704}
> (gdb) print m_logSize[thread]
> $3 = 0
> (gdb) print m_tm_contextAddress[thread]
> $4 = {m_address = 5144576}
>
> I've been using Gems/LogTM for a while now, setting up my own TM 
> workloads and so on, and in all this time I've never run into this 
> kind of TLB miss when initializing the transactional state  
> (set_transaction_registers). I believe I have done nothing different 
> this time for workload setup.
> Is there anything I can do to avoid this assertion? Any comment will 
> be appreciated.
> Regards,
>
> Ruben
>
> --
> Rubén Titos
> Parallel Computing and Architecture Group
> Computer Engineering Dept.
> University of Murcia
> http://skywalker.inf.um.es/~rtitos/ 
> <http://skywalker.inf.um.es/%7Ertitos/>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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.
>
>