Re: [Gems-users] A question in LogTM

["Mike Marty" <mikem@xxxxxxxxxxx>]

> 
> Thanks for confirming this bug.
> My suggestion is that why not deal with R/W bit in
> CacheMemory::tryCacheAccess()?
> By disabling fast path, all transaction load/stores need extra cycles to
> complete. It will be a big penalty and may kill much of the speedup of
> LogTM.

Thanks for the suggestion.  I'll pass this on to the maintainers of the
LogTM portion of GEMS.  

> In fact the same problem exists not only for LogTM. Any fast path store
> fails to setup the 'Dirty' bit just as the R/W bit problem here.
> 

The dirty bit should indeed get set because it won't be a fast-path store
(tryCacheAccess should return false if the line isn't dirty).  I agree that
it seems checking the R/W bit here would too make sense, but I am really not
familiar with the SMP LogTM implementation.   

I think the whole idea of fast-path was a bad idea and a kludge to allow a
single controller for both the L1 and L2.  Fortunately for the CMP
protocols, which are more relevant nowadays, fast-path is not needed.