> In the case of a multi-core system as you said, the second bin (linked > list) would potentially have more than a single event to be set for > execution at a particular cycle, and although the current structural > order implementation for execution is set for LIFO, there is no > guarantee as to the relative order. I can see this as tending to be > towards a more realistic approach, as real systems would be > indeterministic in this regard. > > However, regardless of the order in which the events are executed, > would you say or in some sense 'guarantee' that the events listed in > the bin, would execute corresponding to the same timestamp cycle? > > For example, if the 'when' timestamp corresponded to simulation cycle: > 1000, and assume that all the priority levels of the events are > equivalent, > > if the order in which 5 events let's say in the bin are executed in the order: > > event 1 -> event 3 -> event 2 -> event 5 -> event 4 > > at simulated cycle 1001: would these particular events have already > been set for execution? I don't know what you mean by "set for execution". At cycle 1001, all events from times < 1001 would have been executed and removed from the queue.
> Also, how does the number of cpus determine (if it does assumingly) or > impact whether or not the bin of events for a particular cycle is > empty or not in the subsequent cycle? For example, would an event be > scheduled onto an available core? events aren't scheduled on cores. Events are scheduled on the event queue. A core has some sort of clock event that must be scheduled to start the clock and must be rescheduled every cycle to schedule it for the next cycle. Events don't persist on the event queue. > It seems from your previous response that it is possible to have more > events scheduled at the same time then there are available CPUs, and > depending on which cpus's generated the event request, does that mean > some of the events may not be set in execution at that particular > timestamp (due to data hazards/dependencies or cpu resources?) Events can be scheduled for any reason. It depends on the design of the module. It seems that you might be confused about the relationship of events and cores. Events are created by any module to schedule something to happen in the future. Those events are scheduled on an event queue which dispatches those events in time/priority order. A dispatched event may do anything from report the response message of a cache operation to doing the main clock function of a core. > Moreover, from your previous response it seems that it is possible > (even if it is not the common case) for a single thread/core to set > for execution more than a single event (whether or not in a multi-core > system, if we just concern ourselves from perspective of a single > thread/core). Yes, that is possible. > I see that there are functions available for event rescheduling, that > would deal with such situations, but just to confirm, once an event is > placed in this main queue, all such possibilities of needing to > reschedule have already been determined, such that at this point, > there is no reason for it to be rescheduled or not be executed? No, that is not true. An event can be rescheduled. For example, I may schedule an event for 50 cycles in the future and find out in 10 cycles that it should have been scheduled sooner. In that case, I may choose to reschedule the event. Alternatively, I could use an event for some sort of timeout (like a watchdog clock). In that case, I'll schedule the event for a fixed time in the future, but if the clock gets reset, It will be rescheduled further in the future. I think you're trying to make the event system more complicated than it is. It is effectively a heap where the top element is dispatched. The only rule about insertion is that you can't insert an event in the past. There aren't any restrictions on removing events from the queue. Nate _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
