Hi, Currently, for each trace record we create a Ruby request by calling Sequencer::makeRequest. Later, in RubyEventQueue::scheduleEventAbsolute they will be scheduled (pushed back) on the prio_heap.
To implement the new cache warmup, I can similarly call Sequencer::makeRequest, but then where is the best place to schedule these events on mainEventQueue instead of RubyEventQueue/prio_heap? Thanks, Somayeh > On Fri, Jun 24, 2011 at 4:01 PM, <[email protected]> wrote: > >> Hi, >> >> I like Steve's idea. The basic idea is similar to the current >> implementation (i.e., having a second event queue) but without hijacking >> Ruby APIs. >> >> I have a question regarding Nate's and Steve's discussion on the head >> pointer. Do I need to have a swap function implemented or I can make the >> pointer public and change it (e.g., set it NULL)? >> > > We definitely don't want to just make the pointer public... something like > a > swap method is much preferred. > > Steve > > > >> >> Thanks, >> Somayeh >> >> > On Fri, Jun 24, 2011 at 11:52 AM, nathan binkert <[email protected]> >> wrote: >> > >> >> > Your latest suggestion is very similar to how the current patch >> works. >> >> The only difference is that the Ruby event queue shim layer does a >> >> logical >> >> pointer swap and not a physical pointer swap within the main gem5 >> event >> >> queue itself. I'm somewhat leery of making the event queue head >> pointer >> >> public, but if you're ok with it, then I'll go along with it. It >> >> certainly >> >> will be less work for Somayeh...no need to worry about events >> scheduling >> >> past T-1 ticks, etc. >> >> >> >> Let's definitely not make the head pointer public. I think that the >> >> right thing to do is create a swap() function (for those of you that >> >> don't know, swap is a very common concept in the STL). Then we can >> >> create a temporary queue, swap it with the main queue, run >> everything, >> >> and when it is done, swap it back. The swap function would be >> public, >> >> but nothing else would be. >> >> >> > >> > Agreed, I was about to say something similar but you beat me to it. >> This >> > could also be done by making the copy and assignment operators public >> > (swap >> > the state out by copying it to a new object, restore by assigning the >> > state >> > back). >> > >> > Of course, we really just want to swap the head pointer and not >> > necessarily >> > the name, so maybe a swap() on the head pointer would be better, but I >> > don't >> > know that it's worth quibbling about whether that happens or not. >> > >> > >> >> This seems to me to be the safest way to ensure that everything works >> >> as expected. I'd also like to see _curTick moved into the eventQueue >> >> itself, and the global curTick() function should call >> >> mainEventQueue.curTick(). (Is this what you've done for your >> multiple >> >> event queue patch steve?) >> >> >> > >> > No, my patch just puts _curTick in TLS using __thread. It's been a >> while, >> > but I'm pretty sure there are places where curTick() gets called where >> you >> > don't have easy access to which queue you're on (e.g., inside of a >> DPRINTF >> > that's not in a method associated with an EventManager object) so you >> > really >> > want a TLS pointer to tell you where you're at. You could put curTick >> in >> > the event queue and then have an EventQueue* in TLS, but that seems >> like >> > an >> > unnecessary indirection, unless it turns out that we need that queue >> > pointer >> > to be in TLS also (which may happen, but I'm not convinced that it >> will). >> > >> > It's an interesting debate to have, but I'd prefer to see it decoupled >> > from >> > Ruby warm-up so that Somayeh doesn't get held up on it. >> > >> > Steve >> > _______________________________________________ >> > 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
