chipsalliance
Failing store conditionals bring the data to cache and mark them dirty
Type of issue: bug report
Impact: unknown
Development Phase: request
Other information
I noticed that in Rocket core when store conditional (sc.w) instructions execute when there is no reservation (sc bound to fail), data in the store address are bought to cache and mark them as dirty.
I don't see a reason why this data needs to be set to dirty as there should not be an actual store happening due to the failing sc. This behavior has an effect on performance as later when there is a cache collision, data that was marked as dirty needs to be written back to memory.
Please let me know the details if this is a known design decision for some reason.
If the current behavior is a bug, please provide the steps to reproduce the problem: test_sc.zip
# Run the test with the following command and see sc instruction at PC 0x8000048c and cache collision with the lb instruction at PC 0x8000049c
./emulator-freechips.rocketchip.system-freechips.rocketchip.system.DefaultConfig +verbose test_sc.elf 2>&1 | spike-dasm |& tee run.sc.log
What is the current behavior? Data is brought to cache and marked as dirty for failing store conditional instructions.
What is the expected behavior? Not setting the dirty bit for failing store conditional instructions (or not bringing them into the cache in the first place, depends on the implementation)
Please tell us about your environment: - version: b503f8ac28a497b2463ffbac84bfe66533ace0bb - OS: Linux 3.10.0-1160.62.1.el7.x86_64 https://github.com/chipsalliance/rocket-chip/issues/1 SMP x86_64 x86_64 x86_64 GNU/Linux
What is the use case for changing the behavior? Fixing this will improve the performance by avoiding unnecessary writebacks.
I suppose this could be optimized if it is known immediately that the sc will fail.
Do you see this situation occurring frequently in some scenario?
The test I attached does not have any load reservation instruction before the store conditional, so I would think that at least this type of failing sc can be detected early. But I don't have a good understanding of the current Rocket implementation to say for certain.
My testing setup has randomly generated tests, so I see this scenario frequently. But I think this can happen in a lock acquiring loop as well (using lr/sc), please correct me if I am wrong.