Hi All, Yesterday a few of us from AMD and Wisconsin met and discussed the next tasks for GEM5. Specifically there are a couple (possibly more?) new graduate students at Wisconsin that are starting to ramp up in the simulator. While we spent some time discussing short-term projects for the new graduate students, the majority of the time was focused on a remaining steps necessary before Ruby can supply data to M5 cpus while using warmed up cache traces. Below is a summary of our meeting as well as a discussion on the possible directions we can take. I'm send this summary out so that other can comment and provide feedback.
Please let me know if you have any questions, Brad Short-term projects for the new Wisconsin graduate students - Incorporate work completed/transaction completed metrics to Simulate.py - Include randomization support into the memory system to simulate multiple execution paths Tasks required before Ruby can supply data to M5 cpus while using a warmed up cache traces. - Add support for cache flushes within the protocols o This mechanism is required by certain x86 instructions and memory types o Furthermore it could be leveraged to create checkpoints that include both valid main memory data as well as a cache warmup trace with valid data. (More on this topic below) - Provide support for allowing certain simobjects to be scheduled on the event queue without advancing sim_ticks o In order to run a cache warmup trace through Ruby, Ruby requests need to be executed and Ruby simobjects need to be scheduled. However, at the end of warmup, the simticks and the rest of the simulator state need to be consistent with the loaded checkpoint. § Currently, we (at AMD) have an internal patch that achieves this functionality by leveraging the fact that Ruby objects still use the Ruby eventqueue API. During this warmup phase, the Ruby eventqueue detaches from the M5 event queue and instead uses the old ruby event queue implementation to schedule events. Once the warmup is complete, the Ruby eventqueue reattaches to the M5 event queue. This obviously is not the real way we want to do this because eventually we want all Ruby events to directly use the M5 event queue API. That is why I don't have plans to check in this current patch to the public tree. o One possible solution would be to identify which events can be scheduled during cache warmup and assume all other events can only be scheduled during actual execution. § I'm interested to know how complicated others believe a solution like that would be? - Once the two above tasks are complete, we should be able to create cache warmup traces with data and also provide valid data in main memory. o The motivation for providing valid data in both the cache trace and main memory is that we maintain the flexibility of allowing each protocol to create their own policies for handling dirty data. o The specific mechanism would be to record the cache trace using Ruby's current CacheRecorder (I've already revitalized this code in GEM5) and then use the cache flush mechanism to flush dirty data to main memory before checkpointing memory. - Add functional access support to Ruby. o One possible way to add functional access support to Ruby is to quiesce or drain outstanding Ruby requests when a dynamic functional access is initiated and actually perform the access after Ruby has been drained of any outstanding requests. § Therefore, if all cache blocks are in a base state, then Ruby can use the protocol independent AccessPremissions on the cache and data blocks to determine which blocks should be read and written. This would only require additional set state operations in the Directory sm files to set the AccessPremissions for a block. The cache sm files already do this so the impact to the protocols would be minimal. § However, the obvious disadvantage to this approach is that every functional access will perturb the timing of the system. o Another possible approach is to add atomic access support to Ruby and utilize this for functional accesses. § Basically instead of using events resulting from the receiving of timed messages to transition between base states, use function calls. § I'm not sure how to make this work, and I fear that it will restrict how protocols are defined. Furthermore, it seems it would be extremely complicated to get these atomic accesses to work while timing accesses are active in the system and cache blocks are already in some sort of transient state. Overall, I suspect this is not easily feasible, but I could be wrong. o A third option is to restrict functional writes to only initialization and allow dynamic functional reads to be only a best effort and not guaranteed to be correct. § I believe Steve has already discussed such a possibility with Nate and Ali. § Functional writes at initialization are trivial to support in Ruby since all blocks are in a steady state. I actually already have an internal patch that provides some of this support. If functional reads are relaxed to be a best effort, than Ruby will almost always succeed reading valid data using AccessPremissions without quiescing the system and only rarely fail because a block is in a transient state. Other outstanding tasks to keep in mind - Merging stat files o We've discussed this in several previous emails, but I just wanted to reiterate it here. - Allow I/O requests/responses and interrupts to flow through the Ruby network. o Currently these are simply routed to a classic M5 bus, but these should be included in the Ruby network. o It will take some effort to make this work, but it shouldn't be too hard.
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
