Brad and I just chatted about this on the phone. The concern that I
believe I share with Nate is that we've worked to make all of these
SimObject traversal loops order-insensitive, and come up with a
multi-stage initialization process that lets you manage dependences on
initialization of other objects without needing order withing any one
stage (see http://gem5.org/SimObjects#Stages_of_initialization), so it
doesn't feel right to us to make a global change that enforces some
ordering just to get this one feature to work. (Especially since Nate
and I agree that the "right" answer is to make Ruby handle atomic
transactions, but I know we need another answer to tide us over until
that day comes.)
If I understand correctly, the purpose for running the event queue
before unserialize() is called on any other (non-Ruby) SimObjects is
to make sure that the events those other objects might schedule don't
interfere with the Ruby cache warm-up. If so, another way to prevent
this interference is to run the Ruby warm-up from time 0 instead of
the restored curTick value. We probably can't guarantee that the
entire warm-up trace will complete before T, but it seems safe to
assume that no single Ruby transaction on an unloaded memory system
will take more than T ticks.
So here's the proposal:
- Move all the magic into RubySystem::startup(), where we know that
all the Ruby objects have been unserialized (along with everything
else).
- In RubySystem::startup(), we:
1. Save the (already restored) curTick() value (call this T).
2. For each transaction in the warm-up trace:
2.1. Set curTick to 0.
2.2. Inject the transaction.
2.3. Call simulate(T-1) to run the transaction. The T-1 arg
will guarantee that we don't run past T.
2.4. Call fatal() if the injected transaction doesn't complete
before T-1.
3. Re-restore curTick to T.
Does this seem reasonable?
Steve
On Mon, Jun 20, 2011 at 5:23 PM, Beckmann, Brad <[email protected]> wrote:
> From my perspective, there is only the second issue you mentioned, advancing
> the simulator event queue to execute the warmup trace. Ruby already uses the
> main event queue, so I view the first issue as some solved, though there is
> still room for improvement.
>
> I didn't mean to imply that Ruby would need to explicitly reset the clock.
> As you suggested, if Ruby is the first thing unserialized, the curTick will
> be reset correctly when the root object is unserialized. Similarly when
> states are reset, all Ruby stats incremented during the warmup phase will be
> reset. Assuming we can get the unserialized order correct, everything should
> just work without any explicit resets.
>
> The idea of a second event queue is an interesting alternative. How easy is
> it to point certain SimObjects at one event queue during one period of
> execution and another event queue at a different period?
>
> Brad
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:gem5-dev-
>> [email protected]] On Behalf Of nathan binkert
>> Sent: Monday, June 20, 2011 10:20 AM
>> To: gem5 Developer List
>> Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup
>>
>> > The solution that Somayeh is working on will allow us to remove the ruby
>> event queue API. Ruby already uses the main event queue underneath for
>> all operations except cache warmup. When executing a warmup trace, the
>> event queue must move forward. If Ruby is the first SimObject unserialized,
>> then the event queue can be moved forward when the trace is
>> executed. Subsequently the rest of the system is unserialized and the
>> curTick is set the appropriate value.
>>
>> Ok. Maybe I didn't understand what's going on. There are two separate
>> issues. One is that you're planning to switch to the main event queue. The
>> other is that when executing the warm up trace, you need to advance the
>> simulator clock, right? Because of the second, you're expecting to advance
>> the clock to run the warmup trace and then put the clock back to the start
>> value. I'd like to suggest that you just advance the clock while running the
>> warmup trace and you leave it. If you reset statistics, nothing will ever
>> notice. I worry that advancing the clock and then moving it backwards in
>> time
>> can cause some major problems. Actually you may still run into problems
>> because of other things that are scheduling events on the event queue (like
>> real time clock interrupts, device interrupts, etc.).
>>
>> Another option is to create a second event queue (which Steve has made
>> possible), run the warmup on that queue, and then switch Ruby to the main
>> queue and discard the warmup queue.
>>
>> Is there really no way to replay the warmup without advancing the clock?
>> This is the type of thing that atomic mode is good for.
>>
>> Nate
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>
>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
