chipsalliance / chipsalliance/rocket-chip
Failing store conditionals bring the data to cache and mark them dirty
- Dominant language
- Scala
- Stars
- 3.9k
- Forks
- 1.3k
- Avg merge
- 5d 13m
- Merged PRs (30d)
- 1
Description
**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](https://github.com/chipsalliance/rocket-chip/files/9305801/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.
Contributor guide
Research direction
Start with the attached test_sc.zip and run the provided emulator command on the reported version. Inspect the store-conditional at PC 0x8000048c and the cache collision with the lb at 0x8000049c. Done means a failing sc.w no longer marks the affected cache data dirty, or does not bring it into the cache, without unnecessary writebacks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100