Right now it's possible the redefine the mandatoryQueueLatency function to return the cache latency, but this only works for L1 hit latency. It's currently not possible to have a fully generic model since each protocol can have different assumptions regarding how a cache lookup/update latency would affect each transaction.
Best, Tiago ________________________________ From: Shehab Elsayed <shehaby...@gmail.com> Sent: Thursday, May 14, 2020 11:50 AM To: gem5 users mailing list <gem5-users@gem5.org> Cc: Tiago Muck <tiago.m...@arm.com> Subject: Re: [gem5-users] Question about Ruby cache latencies Thank you very much for your reply and explanation, Tiago! Wouldn't it be more generic to add the latencies at the time of performing the access in the cache itself instead of having it in the controllers since any cache access should incur access latency? I am not sure how easy that would be though given the way ruby works right now. I don't know the exact details of ruby operation but I took a quick look and noticed that getEntry(...) can be called multiple times for the same request which, I guess, makes my suggestion more difficult to add. On Tue, May 12, 2020 at 12:11 PM Tiago Muck via gem5-users <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> wrote: Hi Shehab, Your understanding is correct, there are some cases that are not being handled. This https://gem5-review.googlesource.com/c/public/gem5/+/18414 patched MOESI_CMP_directory to some extent (there was no cache latency being considered before) but was not a complete solution. Other then the case you mentioned, MOESI_CMP_directory is also currently missing the transaction annotations so it can generate stalls on cache/directory bank access conflicts. Best, Tiago IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org<mailto:gem5-users@gem5.org> To unsubscribe send an email to gem5-users-le...@gem5.org<mailto:gem5-users-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
