Re: [Gems-users] what is TSO?

[Dan Gibson <degibson@xxxxxxxx>]

Enrique,

Enrique Vallejo Gutiérrez wrote:
> Dan,
>
> Thank you for your quick and clear answer. It is interesting to know 
> that DATA_BLOCK is going to be deprecated; it is quite hard to 
> understand how Gems works just from searches in the code, and this 
> sort of hints helps.
DATA_BLOCK is already deprecated in many ways. Notably, DATA_BLOCK=true 
breaks Ruby under certain conditions (though no effort has been made to 
fix DATA_BLOCK, except for the the LogTM protocols).
> Regarding the memory consistency, I haven’t tried to implement TSO, 
> but it seems quite straightforward like you are explaining. However, 
> as you point out, there might be quite many problems, from two 
> different sources:
>     * The behaviour on memory barriers and serializing instructions
>     * Possible execution problems (as now Simics wouldn’t provide
>       correct simulation for sure)
The saving grace for a TSO implementation is that SPARC is a TSO model, 
hence *Solaris* should be OK with a _correct_ TSO implementation. TSO is 
also reasonably close to SC, in that you only get in trouble if you 
start making your own home-grown synchronization. Further relaxing 
memory ordering might be troublesome.
>    *
>
>
> You say that you have worked with consistency models and the “snoop 
> model” interface, it would be interesting to know your experience in 
> the area. Given that Gems can simulate a TSO timing, do you consider 
> that running a TSO code with this TSO option in Gems would provide an 
> accurate result (without using this “snoop model”)? By accurate I mean 
> that the speedup over a SC code executing with the normal 
> implementation (not TSO in Gems) would reflect realistic values, or 
> there might be any detail that makes these values unrealistic (always 
> having a SC ordering might influence the result?)
First of all, the TSO flag isn't tested against all protocols. We have 
not used the TSO flag internally for some time now (~1 year). However, 
the TSO flag *should* be orthogonal to protocol choice (module LogTM). 
Since the protocols will work with out-of-order machines, the store 
buffer shouldn't disturb things too much. Provided the store buffer has 
room, the processor won't block on a store miss.
I would say that GEMS is capable of simulating aggressive TSO timing, 
but will of course (in its current form) produce only SC results.
> Finally, it is interesting to hear about the details of the Simics 
> MAI, though Gems does not use it.
Yes, GEMS predates MAI, though Ruby has been ported by others to 
interact with MAI-OOO implementations. The Simics documentation on MAI 
is short enough to read in about an hour or so, which is both convenient 
and not.
Regards,
Dan
> Regards,
>
> Enrique Vallejo
>
> University of Cantabria, Spain
>
> ------------------------------------------------------------------------
>
> *De:* gems-users-bounces@xxxxxxxxxxx 
> [mailto:gems-users-bounces@xxxxxxxxxxx] *En nombre de *Dan Gibson
> *Enviado el:* martes, 10 de octubre de 2006 15:45
> *Para:* Gems Users
> *Asunto:* Re: [Gems-users] what is TSO?
>
> Enrique,
>
> First off, thanks for the detailed post on TSO timing in Ruby.
>
> As far as plans for modeling actual TSO functionality and timing--we 
> have none. It wouldn't be terribly difficult, however, to do so. 
> Notably, previous versions of Ruby have stored data in caches (the 
> now-mostly-deprecated DATA_BLOCK flag) by default, and Ruby has the 
> capability of behaving as a Simics "snoop device" in addition to a 
> "timing model" (Simics terminology, somewhat unclear).
> {ASIDE:
> "Timing models" provide stall times to the Simics processors -- they 
> do not affect memory values.
> "Snoop devices" can overwrite values observed by memory read operations.
> }
>
> Hence, by using both the timing and "snoop" options, it is possible to 
> implement the timing and functionality of TSO, though various 
> considerations would have to be made for memory barriers and 
> serializing instructions (probably nontrivial).
> I personally have done some work (on unreleased code) that uses the 
> snoop model. I can tell you that it is quite easy to use. Have a look 
> at ruby.c if you're interested--setting phys_mem0's "snoop model" 
> attribute to Ruby enables the snoop model.
> Lastly, if changing Simics versions isn't too painful, I recall Simics 
> 3.x uses a more exposed memory consistency controller (under MAI), 
> which can be forced to implement other models. It might be simpler to 
> implement TSO as processor-side functionality under Simics 3.x.
> Regards,
> Dan
>
> Enrique Vallejo Gutiérrez wrote:
>
> Hi,
>  
>         I recently asked some questions regarding consistency issues in GEMS
> (see
> https://lists.cs.wisc.edu/archive/gems-users/2006-October/msg00008.shtml)
> and this is a similar issue. 
>  
>         As far as I understand from the code, if TSO==true (default: false)
> then Ruby would actually simulate the data values in the StoreBuffer (search
> TSO in $GEMS/ruby/system/Sequencer.C). Also, if DATA_BLOCK==true (default:
> false), then the cache blocks in Ruby would actually hold the memory values:
> $GEMS/ruby/system/DirectoryMemory.C loads the data from Simics as needed,
> and $GEMS/ruby/common/DataBlock.C is initialized with a size defined by
> g_DATA_BLOCK_BYTES, this is, some space is reserved for the data in the
> caches. This is also used, for example, for the log buffer in LogTM
> protocols (which holds the clean DataBlocks of a transition, and restores
> the main memory from them if needed).
>  
>         However, to make Ruby follow a TSO model, Simics is needed to read
> the value held in Ruby, instead of the value from Simics global memory. If
> only Simics processors are stalled/unstalled, then the values that Loads
> receive are the values from Simics global memory image. Modifying the loaded
> value can be implemented with a "snoop-memory" interface in Simics, which is
> in fact registered in $GEMS/ruby/module/ruby.c. The callback function (the
> function which Simics calls after the memory operation, that can modify the
> value) is observeMemoryAccess, in $GEMS/ruby/simics/SimicsProcessor.[Ch].
> However, this function has the operations that modify the value commented,
> *returning always the global value from Simics' memory* (There is a "NOT
> IMPLEMENTED" comment). 
>  
>         If the consistency model was TSO, then the actual values should be
> modified in this function; however, as Mike pointed me previously, this
> wouldn't be a Timing-first simulation any more: part of the "correctness" of
> Simics is moved to GEMS. As far as I know, if this was correctly programmed
> (which is not so trivial), Solaris might work perfectly, as it is designed
> to work on TSO SPARC processors. However, in case of an error, GEMS would
> not be able to rely on Simics to provide a correct execution (as GEMS has
> modified the correct execution of Simics).
>  
>         Considering this, with the current code the resulting consistency
> model would always be SC. This seems to be a little "tricky", as it provides
> the speed advantage of TSO (values can be received from the local
> StoreBuffer before being globally visible, for example) without the
> disadvantages (subtle memory arrangements which make SC code not working on
> all cases, need for synchronization instructions). However, any valid SC
> memory ordering is always a valid TSO ordering (but not the other sense).
>  
>         As a final question, are there any plans to work further on this
> memory consistency area? I hope that these comments are accurate and of any
> help, correct me if I had any mistake.
>  
>         Regards,
>  
> Enrique Vallejo
> University of Cantabria, Spain
>  
> -----Mensaje original-----
> De: gems-users-bounces@xxxxxxxxxxx <mailto:gems-users-bounces@xxxxxxxxxxx> [mailto:gems-users-bounces@xxxxxxxxxxx]
> En nombre de Dan Gibson
> Enviado el: lunes, 09 de octubre de 2006 21:15
> Para: Gems Users
> Asunto: Re: [Gems-users] what is TSO?
>  
> Ruby can simulate the timing of the TSO memory model for some protocol 
> options. It does NOT simulate the data values. You'd have to look at the 
> code to see which protocols this will work with the TSO flag.
>  
> Mike Marty wrote:
>   
> > Total Store Ordering memory consistency model
> >  
> >  
> >   
> >     
> > > Hello,
> > >  
> > > I have noticed some operations related with "TSO" in
> > > Sequencer.C, could you please tell me what TSO is and
> > > why it is used for?
> > >  
> > > Thanks.
> > >  
> > > DZ
> > >  
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > > _______________________________________________
> > > Gems-users mailing list
> > > Gems-users@xxxxxxxxxxx <mailto: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 <mailto: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.
>
>   
--
http://www.cs.wisc.edu/~gibson [esc]:wq!