Hi Somayeh, As long as you don't set the cache warmup flag in the ruby event queue shim layer, the ruby event queue calls will schedule events on the main event queue. All you have to do is remove that enableCacheWarmup call in the Tracer::playbackTrace function.
Brad > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Sunday, June 26, 2011 1:42 PM > To: Beckmann, Brad; Steve Reinhardt > Cc: gem5 Developer List > Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup > > 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
