Hi Gabriel, Thanks for your reply! Your explanation really clears things up for me, as I was not taking sub-cacheline-granularity accesses from the core into account. Yes, i believe that the current sequencer indeed will block subsequent loads accessing the same cacheline from happening, and such cases as the one i fathom will not actually happen.
-----Original Messages----- From:"gabriel.busnot--- via gem5-users" <gem5-users@gem5.org> Sent Time:2023-03-23 17:05:18 (Thursday) To: gem5-users@gem5.org Cc: gabriel.bus...@arteris.com Subject: [gem5-users] Re: Question Regarding L1 Cache Transient States handling Load Hit in Ruby MOESI CMP Directory protocol Hi Zhang, Did you observe that behavior during a simulation or is your observation solely based on your analysis of the protocol definition? If you did observe that behavior, then I think it should be considered a bug but not necessarily from the protocol. First, it would be a bug in the sequencer that interfaces the core and the L1 and is responsible, among other things, for sequencing requests to the same line, that is, not initiating a request to a line until the previous request to that line has completed. Second, it could be considered a bug from the core if and only if the store and the subsequent read to a given cacheline target overlapping ranges. AFAIK, the very semantics of store instructions in any ISA is that subsequent loads from the same thread shall observe the effect of the latest store (multi-threaded observability is another kettle of fish). It is up to the core to go get the data where it is if a store is still ongoing at the time of issuing a load, whether it is in a cache, a store buffer or anything. But, if the core’s pipeline can assume that the memory requests sent downstream will be handled sequentially anyway, then it’s fine to issue requests back to back without waiting for completions. This is what the sequencer should enable so the core model is not at fault in gem5. Then comes the cache itself and the coherency protocol. In CMP-directory, the L1 does respond to loads targeted at lines with an ongoing store (SM state). This is fine if the load and the store target different addresses in that line. If not, then I think that we are in the realm of undefined behavior as you have a race between an ongoing store and a load. In practice, you will get stale data with the CMP-directory protocol. Will you be able to observe such issue in practice? I don’t think so as I believe the Sequencer to be fairly robust and doing its sequencing job reliably. BTW: the sequencer operates at the cacheline granularity to detect aliasing. This is sub-optimal and prevents protocols like CMP-directory to respond to requests as soon as possible. Granularity should probably be smaller but that change might have subtle side effects on the other operations of the sequencer. Regards, Gabriel -- 姓名：章志元 手机：17717877306 邮箱：zhiyuanzhan...@fudan.edu.cn
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
