Hello everyone

I’m an undergraduate student and going to embark on a journey to extend the protocol for MESI_Three_Level at the memory level to MSI or MESI, as opposed to the two-state MI that it is right now. Does anyone have any tips or advice for this journey, perhaps one of you has done something similar or already have this implemented?

I understand that at a minimum, this requires modifying both the memory SLICC protocol and also the last level cache.

Thanks a lot,
Arteen
UCLA

Not sure about this, but I have looked at MOESI_CMP_Directory as it supports sharing/owning  in clusters. Maybe you can think of directory, and L1, L2 as a three level system and get inspiration from there.

Thanks and Regards,
Gautam Pathak
David R. Cheriton School of Computer Science
University of Waterloo

From: Arteen Abrishami via gem5-users gem5-users@gem5.org
Sent: Wednesday, October 11, 2023 6:06 AM
To: The gem5 Users mailing list gem5-users@gem5.org
Cc: Arteen Abrishami arteen1000@gmail.com
Subject: [gem5-users] MSI Protocol at Memory

Hello everyone

I’m an undergraduate student and going to embark on a journey to extend the protocol for MESI_Three_Level at the memory level to MSI or MESI, as opposed to the two-state MI that it is right now. Does anyone have any tips or advice for this journey, perhaps one of you has done something similar or already have this implemented?

I understand that at a minimum, this requires modifying both the memory SLICC protocol and also the last level cache.

Thanks a lot,
Arteen
UCLA

gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-leave@gem5.org

Hi Arteen,

If you are not tied to the MESI_three_level protocol, then, as Gautam said, you might want to switch to a different protocol that already supports the shared state in the system level cache. CHI is the most advanced and configurable protocol in that respect but others might do as well like MOESI_CMP_Directory.

If you must stick to MESI_three_level, then you will have to modify at least the directory to add a shared state that you transition to when sending read only data as a result of a GETS and there is only sharers (or no sharer at all). You will also have to modify the L2 to forward clean data as shared instead of exclusive. Several other modifications will be required along the way to issue the correct snoops, respond appropriately, etc.

I am probably still overlooking several subtleties that will show up along the way, though. Overall, you are trying to change a pretty fundamental design aspect of the MESI protocol which is always assuming dirty data in caches from directory perspective. This enables certain silent transitions in the caches (typically, exclusive to modified) that will not be allowed in case the directory is in the shared state.

If you still want to give it an attempt, you should use the ruby_mem_test.py coherency test configuration script together with the ProtocolTrace debug flag and possibly the Ruby debug flag for lower level issues.

Regards,

Gabriel