I have a new tree based event queue that I've been using for several months. A side effect of the new design is that it's now FIFO. I'll get it committed when we get our source tree sorted out.
Nate 2008/5/13 Steve Reinhardt <[EMAIL PROTECTED]>: > Thanks for bringing it up again... I will try and remember to get it fixed. > > Steve > > > 2008/5/13 KE MENG <[EMAIL PROTECTED]>: > > > > > > Yes, I agree with that. > > > > > > > > ________________________________ > Date: Tue, 13 May 2008 10:02:12 -0700 > > From: [EMAIL PROTECTED] > > > > > > > > > > To: [email protected] > > Subject: Re: [m5-users] a bug report > > > > I think you're misidentifying the bug here. You should never rely on > events being processed in a particular order based on the order they're > inserted in the event queue. The whole point of the priorities is to give > you explicit control over the order in which events in the same cycle get > processed. > > > > If you get different results based on whether events with the same > priority on the same cycle get serviced in FIFO or LIFO order then that's > the bug, and the fix is to give the events different priorities to make FIFO > vs LIFO irrelevant. > > > > Steve > > > > > > > > 2008/5/13 KE MENG <[EMAIL PROTECTED]>: > > > > > > Well, actually I also reported this as a bug a few months ago. The > difference here is how two events with same priorities and scheduled time > are put in the queue. In current code, later arrived events would be put in > front of other events which have the same priorities and scheduled time, and > this means some later arrived events would get handled first. Under most > circumstances this is probably ok. But for other, it's not neccessarily > appropriate. For example, for an Icache of 1 latency cycle, an > instruction-fetch would put a cache accessing event on the queue. Supposely > it shoud get handled and the instructions would be returned in next cycle. > But since a cpuTick event has a same priority and the tickEvent for next > cycle would be actually put in front of the cache accesing event when it is > scheduled later. So in next cycle, the tickEvent would be handled first and > it has to wait for the access to return yet. In this way, the actual latency > of the Icache becomes 2 cycles. For the same reason, I also changed the > following lines > > > > > > > > > > if (head == NULL || event->when() < head->when() || > > (event->when() == head->when() && > > event->priority() <= head->priority())) > > > > to > > > > > > if (head == NULL || event->when() < head->when() || > > (event->when() == head->when() && > > event->priority() < head->priority())) > > > > > Date: Tue, 13 May 2008 05:35:56 -0700 > > > From: [EMAIL PROTECTED] > > > To: [email protected] > > > Subject: Re: [m5-users] a bug report > > > > > > > > > > > > The statements are equivalent. It is written the way it is because it > > > can fail after just one comparison. In the version that you've shown, > > > two comparisons must be made. > > > > > > Nate > > > > > > 2008/5/13 fractal218 <[EMAIL PROTECTED]>: > > > > Hi, > > > > Do you think the following program in function void > EventQueue::insert(Event > > > > *event) is a bug? > > > > > > > > if (event->when() <= curr->when() && (event->when() < curr->when() || > > > > event->priority() <= curr->priority())) > > > > break; > > > > > > > > I think it should be the following: > > > > > > > > if (event->when() < curr->when() || (event->when() = curr->when() && > > > > event->priority() <= curr->priority())) > > > > break; > > > > > > > > > > > > ________________________________ > > > > > > > > 快来用音乐为奥运加油 > > > > 得奥运会、演唱会门票 > > > > _______________________________________________ > > > > m5-users mailing list > > > > [email protected] > > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > > > > > > ________________________________ > Get news, entertainment and everything you care about at Live.com. Check it > out! > > > > > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > > > > > > > > > > > > > > ________________________________ > Get news, entertainment and everything you care about at Live.com. Check it > out! > > > > > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
