Hi guys, I merely wanted to say that I really encourage the discussion. There are plenty trade-offs in the implementation of the coherency protocol, and I am sure there are “unintentional features” lurking in the implementation.
Andreas From: Nizamudheen Ahmed <[email protected]<mailto:[email protected]>> Date: Monday, 5 January 2015 03:44 To: biswabandan panda <[email protected]<mailto:[email protected]>> Cc: gem5 users mailing list <[email protected]<mailto:[email protected]>>, Andreas Hansson <[email protected]<mailto:[email protected]>> Subject: Re: [gem5-users] UpgradeReq command and impact on next-level cache Hi Biswa, Thanks for clarifying on the GEM5 implementation and your thoughts on invalidation. I wanted to experiment on these lines and wanted to bounce the idea with the community. Thanks. BR/Nizam On Sun, Jan 4, 2015 at 10:11 PM, biswabandan panda <[email protected]<mailto:[email protected]>> wrote: Hi, As gem5 uses non-inclusive hierarchy, the 1st point is not applicable. Your second point makes sense. It is not mandatory to invalidate at the LLC. The block at the LLC should be invalidated if the hierarchy is an exclusive one. What gem5 does is at a given instant of time, It makes sure that only one cache is the owner (across all L1s and L2) So it invalidates at the L2 also. On Sun, Jan 4, 2015 at 8:53 PM, Nizamudheen Ahmed via gem5-users <[email protected]<mailto:[email protected]>> wrote: Hi Andreas, iMHO, There are a couple of cases where it may not be required to invalidate line in lower levels 1. Inclusive caches: I would assume that the lower level inclusive caches should , by definition of inclusiveness, hold all the lines a higher level cache has. 2. Shared last level cache: the last level cache (the cache just ahead of main memory) may choose to not invalidate the line on a upgradereq. Rational: as long as exclusivity is maintained by private cache in earlier level, share LLC is strictly not required to invalidate the line on upgradereq. Kindly correct me if implicit assumptions I am making is distorting the reasoning:) Thanks and regards Nizam Sent from my iPad On 04-Jan-2015, at 6:15 pm, Andreas Hansson <[email protected]<mailto:[email protected]>> wrote: Hi Nizam, What do you suggest the lower-level cache should do? The UpgradeReq is ultimately there to ensure that a cache can get a line in exclusive state (E) to perform a write (M). Andreas From: Nizamudheen Ahmed via gem5-users <[email protected]<mailto:[email protected]>> Reply-To: Nizamudheen Ahmed <[email protected]<mailto:[email protected]>>, gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Sunday, 4 January 2015 08:47 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: [gem5-users] UpgradeReq command and impact on next-level cache Hi, I am using classic memory-model in GEM5. I observed that an UpgradeReq command invalidates the line in cache. This behavior is acceptable for peer-caches in the same-level. However, i am not sure if the UpgradeReq should invalidate the cache line in the lower level caches (Caches closer to the main-memory are lower levels, in my terminology). Can someone through light on this? BR/Nizam -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-users mailing list [email protected]<mailto:[email protected]> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- thanks®ards BISWABANDAN http://www.cse.iitm.ac.in/~biswa/<http://www.cse.iitm.ac.in/%7Ebiswa/> “We might fall down, but we will never lay down. We might not be the best, but we will beat the best! We might not be at the top, but we will rise.” -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
