Just to (I hope) clarify: - Andreas is right, even though using recvRetry() to set a flag that gets polled would work, if you're polling every tick that would be inefficient, particularly if the CPU would be sleeping otherwise (i.e., not having its tick event scheduled). If the CPU is sleeping, then setting a flag and waking it up would not be so bad. If the CPU is doing something every cycle anyway, then the relative overhead is smaller.
- Events and communication are more decoupled on the M5 side of things than they are in Ruby. This is potentially confusing but also can enable higher performance (since it allows modules to communicate without forcing them to schedule events to do so, and events are expensive). Clearly the recvRetry() call is triggered by some event in the cache freeing up some resources and calling sendRetry() on its side. If the CPU really needs a separate event to handle the consequences. it can always schedule a new event of its own in recvRetry(). Steve On Tuesday, November 15, 2011, Andreas Hansson wrote: > The cache does indeed invoke a function in the LSQ later in time, once it > is unblocked. The cache is blocked due to some other module in turn being > blocked, right? It is not necessarily just a matter of waiting a specific > time. Once the cache is unblocked it calls sendRetry on its port, which in > turn ends up as a recvRetry call on the connected module (in this case the > LSQ). Effectively the event that unblocks the cache eventually leads to the > LSQ getting called (either directly or through scheduling another event > that does it), and that in turn should result in the sender (here the LSQ) > calling sendTiming. The time between these events is arbitrary and could be > 0, 10s, 100s or 1000s of cycles. > > Andreas > > -----Original Message----- > From: [email protected] <javascript:;> [mailto: > [email protected] <javascript:;>] On Behalf Of Nilay > Sent: 15 November 2011 13:37 > To: gem5 Developer List > Subject: Re: [gem5-dev] Need for recvRetry() > > In an event based simulation, I would expect the cache module to insert an > event into the event queue which will make the simulator invoke some > particular function of the LSQ later in time. In this case, the cache > itself is invoking some function, which in my understanding is not really > event based simulation. > > -- > Nilay > > On Tue, November 15, 2011 2:43 am, Andreas Hansson wrote: > > The overall idea with event-based simulation is to _not_ evaluate > > conditions on a cycle to cycle basis, and only schedule something once > > there is useful work to do (although not every component in gem5 adopts > > this approach). Thus, if you connect something other than a CPU to a > cache > > (say a GPU or some other accelerator) then you should _not_ rely on that > > module polling a status bit or flag. > > > > Sounds reasonable? > > > > Andreas > > > > -----Original Message----- > > From: [email protected] <javascript:;> [mailto: > [email protected] <javascript:;>] On > > Behalf Of Steve Reinhardt > > Sent: 14 November 2011 19:36 > > To: gem5 Developer List > > Subject: Re: [gem5-dev] Need for recvRetry() > > > > I believe that should work. The ability to send a packet from within > > recvRetry() is just intended as a convenience; if you don't return one, > > but > > call sendTiming() later, it should have the same effect, especially if > > it's > > something like an L1 cache where you don't have to worry about some other > > requester stealing the resource that's now available before you can get > > it. > > > > Steve > > > > On Mon, Nov 14, 2011 at 11:06 AM, Nilay Vaish > > <[email protected]<javascript:;>> > wrote: > > > >> Well, the lsq, in every cycle, executes a function that checks whether > >> or > >> not the cache is blocked. I would rather prefer that some variable is > >> set > >> in recvRetry(), which indicates that the cache is now available for > >> servicing requests. Putting the code for sending packet in recvRetry() > >> seems to be introducing more complexity than necessary. > >> > >> -- > >> Nilay > > _______________________________________________ > gem5-dev mailing list > [email protected] <javascript:;> > http://m5sim.org/mailman/listinfo/gem5-dev > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > gem5-dev mailing list > [email protected] <javascript:;> > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
