Hi Nilay, With regards to your question about how to allow multiple simultaneous stores, do you not believe my second and third proposals achieve that?
As I stated before, I don't think we need to make any fundamental changes to Ruby. We just need to provide the correct information and interfaces to the LSQ/Store Buffer. Brad > -----Original Message----- > From: Nilay Vaish [mailto:[email protected]] > Sent: Tuesday, November 08, 2011 6:12 PM > To: Beckmann, Brad > Cc: Default; Mark D. Hill > Subject: RE: Review Request: Forward invalidations from Ruby to O3 CPU > > On Wed, 2 Nov 2011, Nilay Vaish wrote: > > > On Fri, 28 Oct 2011, Beckmann, Brad wrote: > > > >> Let’s move this conversation to just the email thread. > >> > >> I suspect we may be talking past each other, so let’s talk about the > >> complete implementations not just Ruby. There are multiple ways one > can > >> implement the store portion of x86-TSO. I’m not sure what the O3 > model > >> does, but here are a few possibilities: > >> > >> - Do not issue any part of the store to the memory system when the > >> instruction is executed. Instead, simply buffer it in the LSQ until > the > >> instruction retires, then buffer in the store buffer after > retirement. Only > >> when the store reaches the head of the store buffer, issue it to > Ruby. The > >> next store is not issued to Ruby until the previous store head > completes, > >> maintaining correct store ordering. > >> > >> - Do not issue any part of the store to the memory system when the > >> instruction is executed. Instead, simply buffer it in the LSQ until > the > >> instruction retires. Once it retires and enters the store buffer > and we > >> issue the address request to Ruby (no L1 data update). Ruby > forwards > >> probes/replacemetns to the store buffer and if the store buffer sees > a > >> probe/replacement to an address who’s address request has already > >> completed, the store buffer reissues the request. Once the store > reaches > >> the head of the store buffer, double check with Ruby that write > permissions > >> still exist in the L1. > >> > >> - Issue the store address (no L1 data update) to Ruby when the > instruction > >> is executed. When it retires, it enters the store buffer. Ruby > forwards > >> probes/replacemetns to the LSQ+store buffer and if either sees a > >> probe/replacement to an address who’s address request has already > >> completed, the request reissues (several policies exist on when to > reissue > >> the request). Once the store reaches the head of the store buffer, > double > >> check with Ruby that write permissions still exist in the L1. > >> > >> Do those scenarios make sense to you? I believe we can implement > any one > >> of them without modifying Ruby’s core functionality. If you are > >> envisioning or if O3 implements something completely different, > please let > >> me know. > >> > > > > 1. What's current memory model that the O3 CPU implements? Do we want > > multiple memory models to co-exist? We might want to have both SC and > TSO, > > though Alpha had a weaker model. > > > > 2. I think we should try to stick what the O3 CPU implements > currently, > > meaning we should not change the stage when the store is issued to > the cache. > > I am more concerned about how multiple ports get handled. > > > > Looking at the trace generated by the toy application I use for testing > the O3 CPU and Ruby combination, I have been able to confirm my > suspicion > that stores can become visible to the rest of the system in an order > different from the program order. > > It might be that the classic memory system does not allow stores to go > out > of order. Or that the initial implementation of the O3 CPU was for a > weaker memory model like that of Alpha architecture (Prof. Hill > suggested > that this might be the case). > > Overall I am still not clear on how to make O3 and Ruby work together > correctly for SC or TSO, in case when multiple stores can be issued to > the memory system in parallel. > > -- > Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
