Great.  It'd still be nice to have the property that all significant
ordering constraints are encoded via priorities so that FIFO vs LIFO is
irrelevant.

Steve

2008/5/13 nathan binkert <[EMAIL PROTECTED]>:

> 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
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Reply via email to