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 <
gem5-dev@gem5.org> 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
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
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
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 might be able to help as
well.
bump
On Tue, Sep 1, 2020, 12:21 Gambord, Ryan 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
