What specifically marks an x86 cache line as dirty – any write, or is an explicit change required?

by

Currently no implementation of x86 (or any other ISA, as far as I know) supports optimizing silent stores.

There has been academic research on this and there is even a patent on “eliminating silent store invalidation propagation in shared memory cache coherency protocols”. (Googling ‘”silent store” cache’ if you are interested in more.)

For x86, this would interfere with MONITOR/MWAIT; some users might want the monitoring thread to wake on a silent store (one could avoid invalidation and add a “touched” coherence message). (Currently MONITOR/MWAIT is privileged, but that might change in the future.)

Similarly, such could interfere with some clever uses of transactional memory. If the memory location is used as a guard to avoid explicit loading of other memory locations or, in an architecture that supports such (such was in AMD’s Advanced Synchronization Facility), dropping the guarded memory locations from the read set.

(Hardware Lock Elision is a very constrained implementation of silent ABA store elimination. It has the implementation advantage that the check for value consistency is explicitly requested.)

There are also implementation issues in terms of performance impact/design complexity. Such would prohibit avoiding read-for-ownership (unless the silent store elimination was only active when the cache line was already present in shared state), though read-for-ownership avoidance is also currently not implemented.

Special handling for silent stores would also complicate implementation of a memory consistency model (probably especially x86’s relatively strong model). Such might also increase the frequency of rollbacks on speculation that failed consistency. If silent stores were only supported for L1-present lines, the time window would be very small and rollbacks extremely rare; stores to cache lines in L3 or memory might increase the frequency to very rare, which might make it a noticeable issue.

Silence at cache line granularity is also less common than silence at the access level, so the number of invalidations avoided would be smaller.

The additional cache bandwidth would also be an issue. Currently Intel uses parity only on L1 caches to avoid the need for read-modify-write on small writes. Requiring every write to have a read in order to detect silent stores would have obvious performance and power implications. (Such reads
could be limited to shared cache lines and be performed opportunistically, exploiting cycles without full cache access utilization, but that would still have a power cost.) This also means that this cost would fall out if read-modify-write support was already present for L1 ECC support (which feature would please some users).

I am not well-read on silent store elimination, so there are probably other issues (and workarounds).

With much of the low-hanging fruit for performance improvement having been taken, more difficult, less beneficial, and less general optimizations become more attractive. Since silent store optimization becomes more important with higher inter-core communication and inter-core communication will increase as more cores are utilized to work on a single task, the value of such seems likely to increase.

More Related Contents:

  1. Which cache mapping technique is used in intel core i7 processor?
  2. Globally Invisible load instructions
  3. Where is the Write-Combining Buffer located? x86
  4. Difference between x86, x32, and x64 architectures?
  5. Can the simple decoders in recent Intel microarchitectures handle all 1-µop instructions?
  6. how are barriers/fences and acquire, release semantics implemented microarchitecturally?
  7. How do the store buffer and Line Fill Buffer interact with each other?
  8. Why doesn’t GCC use partial registers?
  9. What Every Programmer Should Know About Memory?
  10. Are loads and stores the only instructions that gets reordered?
  11. How much of ‘What Every Programmer Should Know About Memory’ is still valid?
  12. What exactly happens when a skylake CPU mispredicts a branch?
  13. Are there any modern CPUs where a cached byte store is actually slower than a word store?
  14. Lost Cycles on Intel? An inconsistency between rdtsc and CPU_CLK_UNHALTED.REF_TSC
  15. If I don’t use fences, how long could it take a core to see another core’s writes?
  16. x86 registers: MBR/MDR and instruction registers
  17. Is LFENCE serializing on AMD processors?
  18. Why is x86 little endian?
  19. How has CPU architecture evolution affected virtual function call performance?
  20. The most correct way to refer to 32-bit and 64-bit versions of programs for x86-related CPUs?
  21. What kind of address instruction does the x86 cpu have?
  22. What are the costs of failed store-to-load forwarding on x86?
  23. Cycles/cost for L1 Cache hit vs. Register on x86?
  24. What is the difference between Trap and Interrupt?
  25. Branch target prediction in conjunction with branch prediction?
  26. x86 32 bit opcodes that differ in x86-x64 or entirely removed
  27. Are load ops deallocated from the RS when they dispatch, complete or some other time?
  28. Why did Intel change the static branch prediction mechanism over these years?
  29. Are two store buffer entries needed for split line/page stores on recent Intel?
  30. What is the maximum possible IPC can be achieved by Intel Nehalem Microarchitecture?

Leave a Comment