That's fine with me! I love removing code! Cheers, Jason
On Tue, Sep 15, 2020 at 1:08 PM Gambord, Ryan via gem5-dev < [email protected]> wrote: > Hi Srikant, > > Thank you for looking into it. I noticed the miscalculation while working > on something unrelated, and wasn't sure what those values were used for (I > don't need them). If it's not being used, then my proposed change would be > to remove it from the codebase as legacy bloat. Does anyone have a problem > with that? > > Ryan Gambord > <[email protected]> > > > > On Mon, Sep 14, 2020 at 11:44 PM Srikant Bharadwaj via gem5-dev < > [email protected]> wrote: > >> [This email originated from outside of OSU. Use caution with links and >> attachments.] >> Hi Ryan, >> You are right. If the message goes to the next message buffer, delay is >> added again. >> However, as far as I know we are not using the delayed ticks for >> calculating anything anymore. The earlier use case was to calculate the >> stall time within MessageBuffer, but we use the getTime to do that now. >> Is there any specific use case you are trying to fix here? >> >> In any case, it would be great if you can post a fix. >> >> Thanks, >> Srikant >> >> On Mon, Sep 14, 2020 at 10:48 AM Jason Lowe-Power via gem5-dev < >> [email protected]> wrote: >> >>> Hey Ryan, >>> >>> Sorry for the slow reply. Yes, it looks like delayedTicks may be double >>> counting in some cases. I wonder if a little microbenchmark might be able >>> to confirm more clearly? Assuming it is being double counted, we'd welcome >>> a fix! >>> >>> @Bharadwaj, Srikant <[email protected]> might be able to help >>> as well. Srikant, did you see anything like this with Garnet 3.0? >>> >>> Cheers, >>> Jason >>> >>> On Fri, Sep 11, 2020 at 2:35 AM Gambord, Ryan via gem5-dev < >>> [email protected]> wrote: >>> >>>> bump >>>> >>>> On Tue, Sep 1, 2020, 12:21 Gambord, Ryan <[email protected]> >>>> wrote: >>>> >>>>> I noticed that MessageBuffer calls UpdateDelayedTicks in both enqueue >>>>> and dequeue methods. Since dequeue does not setLastEnqueueTime of the >>>>> message to the time it was dequeued at, when enqueue calls >>>>> UpdateDelayedTicks, doesn't it add the dequeue delay to the delayed ticks >>>>> a >>>>> second time? >>>>> >>>>> Below is a table of the timeline. X and Y are the starting values for >>>>> LastEnqueueTime and DelayedTicks when the first message buffer receives >>>>> the >>>>> message. When the message is dequeued from MB1, DelayedTicks gets C-B >>>>> added >>>>> to it. When it is then enqueued in MB2, it gets D-B added, which double >>>>> counts the C-B interval. >>>>> >>>>> curTime() FunctionCall m_LastEnqueueTime m_DelayedTicks >>>>> >>>>> >>>>> X Y >>>>> A enqueue() B = A + Delta Y + (A-X) >>>>> B wakeup() " " >>>>> C dequeue() " Y + (A-X) + (C-B) >>>>> D enqueue() E = D + Delta >>>>> Y + (A-X) + (C-B) + (D-B) = Y + (A-X) + (C-B) + (D-C) + (C-B) >>>>> >>>>> >>>>> Ryan Gambord >>>>> <[email protected]> >>>>> >>>>> _______________________________________________ >>>> gem5-dev mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>> _______________________________________________ >>> gem5-dev mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> _______________________________________________ >> gem5-dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > _______________________________________________ > gem5-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
