Hello Jason, Thanks a lot for your reply! I'm indeed aware that by the cache subsystem doing this, it will give CPU the view of the load as happening before the store. However, in view of the CPU commit order (the instruction order seen by the CPU), the store must have committed before the load, since the store must have been committed before its store miss request could reach L1 cache, thus causing the cacheline state to switch to SM state. I'm actually wondering if the difference between: a. the CPU store->load commit order, and b. the CPU's view of the order of these instructions accessing memory will raise a violation.
Thanks again, Zhang Zhiyuan -----Original Messages----- From:"Jason Lowe-Power via gem5-users" <gem5-users@gem5.org> Sent Time:2023-03-22 23:20:25 (Wednesday) To: "The gem5 Users mailing list" <gem5-users@gem5.org> Cc: "章志元" <18300750...@fudan.edu.cn>, "Jason Lowe-Power" <ja...@lowepower.com> Subject: [gem5-users] Re: Question Regarding L1 Cache Transient States handling Load Hit in Ruby MOESI CMP Directory protocol Hello, This is a great question! The short answer is I believe that the coherence protocol is correct. (Though, there could always be unexpected bugs.) The slightly longer answer: You are probably seeing that the store happens before the load in "real" time. However, in the processors' view (i.e., *logical* time), the load is actually happening before the store. As long as the processors are correctly implementing their consistency models (e.g., if they are sequentially consistent then they don't allow any reorderings between load and store instructions within each thread), then as long as it *appears* that the load completed before the store, then it's a correct implementation. To put it another way, if the thread doing the load cannot tell that the load happened after the store (in real time) then it is safe. It's something like the Lamport Clock: https://en.wikipedia.org/wiki/Lamport_timestamp We have a saying in English: "If a tree falls in a forest and no one is there to hear it, does it make a sound?" Similarly, if a thread does a store to an address, but no other thread can tell what the ordering needs to be, it's OK to reorder it :). Cheers, Jason On Tue, Mar 21, 2023 at 11:50 PM 章志元 via gem5-users <gem5-users@gem5.org> wrote: Hi all, I've been looking into the default MOESI CMP Directory Protocol, and it came to my attention that, regarding SM states in L1 Cache (Transient state during a Shared to Exclusive Upgrade due to a store miss), when a load arrives from the local core (which hits since the Cache is technically still in Shared state), the cache will return the old Shared Datablk as its load hit result. Will it cause incoherence issues in memory ordering between the core and the memory system, since the CPU commits the store first and then commit the load returning the old data, but the memory system sees the load hit finish first, and then see the GETX finish? Also I already speculate that such loads will probably not arrive at the L1 Cache controller, since it would be blocked or forwarded with newer data due to outstanding stores in the lsq or the mandatory queue. I'm just wondering if the cache protocol itself is solid in terms of request ordering. Thanks in advance! Zhang Zhiyuan 2023.3.22 -- 姓名：章志元 手机：17717877306 邮箱：zhiyuanzhan...@fudan.edu.cn _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org -- 姓名：章志元 手机：17717877306 邮箱：zhiyuanzhan...@fudan.edu.cn
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
