Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • Cache Coherency Glossary
  • The Shared Course Model
  • Cache Coherency Revision Sheet
  • Why Coherence Exists8
  • States and Protocols12
  • Transactions12
  • Races and Controller Design8
  • Progress and the Fabric16
  • Ordering and Synchronization12
  • Performance and Scalability12
    • False Sharing
      • True Versus False Sharing
      • Counting Coherence Traffic
      • Padding and Data Layout
      • Finding False Sharing
    • Directory Capacity and Sharers
    • Hotspots and Placement
  • Real Protocols12
  • SoC Integration12
  • Power, Clocking and Reliability12
  • Verification12
  • Debug and Bring-up12
  • Interview and Design Review17
  • Capstone: A Coherent Model Lab5
Loading lesson

‹False Sharing
  1. Topics
  2. Cache Coherency
  3. Performance and Scalability
  4. False Sharing
  5. Finding False Sharing

Part 7 · Performance and Scalability · All levels

Finding False Sharing

Use address, writer and intervention evidence to distinguish a layout problem from true sharing or capacity misses.

What evidence would convince you this is false sharing?

A busy coherence counter does not identify a source field. The method rests on the fourth C. The classic miss types are compulsory (first touch), capacity (the working set does not fit) and conflict (too many lines map to one set). A coherence miss is the fourth: the line was present, but another core's write invalidated it. Coherence misses split at word level. A miss is a true-sharing miss if the word now accessed was written by the other core since this cache lost the line. It is a false-sharing miss if that word was not written by the other core: the line moved only because a neighbouring word was written.

Two generic hardware events expose this. A hit-modified snoop response marks a local miss served from a line another cache holds in M: the data came cache to cache from a dirty copy, the Fwd-GetM case with C0 in M in the course model. It shows that a line is moving between writers, not which word moved it. Precise load/store sampling supplies the word: the core tags sampled memory instructions and records the exact data address, the core and whether the access was a hit-modified miss. Group the hit-modified samples by line (address // 64), then within each hot line by offset (address % 64) and by writing core.

The rule: several offsets in one line, written by different cores, is false sharing. One offset written by several cores is true sharing. In practice, name the target's documented event for the hit-modified response and for precise sampling before trusting either count.

Worked case on the X/Y schedule from Counting Coherence Traffic, sampled after the cold acquisition. Every steady-state store misses on a line the other core holds in M.

Sample

Core and access

Data address

Line, address // 64

Offset, address % 64

Hit-modified?

1

C0 store X

0

0

0

Yes, C1 held M

2

C1 store Y

8

0

8

Yes, C0 held M

3

C0 store X

0

0

0

Yes, C1 held M

4

C1 store Y

8

0

8

Yes, C0 held M

Grouped hot line 0

Offsets and writing cores

Verdict

X/Y schedule

Offset 0: C0 only. Offset 8: C1 only.

Several offsets, different writers: false sharing. Each miss is on a word the other core never wrote.

Truly shared X control

Offset 0: C0 and C1.

One offset, several writers: true sharing. Padding cannot remove it.

Hit-modified samples are grouped by offset and writing core, classified as true or false sharing, then checked with a layout intervention.
Address samples decide true versus false sharing, then a controlled layout change tests the hypothesis.

Keep input, operation count, core affinity and measured interval constant. Record both wall time and the miss counts. Without precise address samples, the hit-modified count alone cannot separate true from false sharing, so mark the attribution as incomplete.

Useful negative controls include a read-only phase, batched writes to the original layout, and the truly shared X variant. A read-only phase should not need repeated write-permission handoffs from these operations. Batching may improve the original layout without changing addresses. Padding should not remove the inherent sharing of one logical X.

A successful investigation ends with a narrow statement: independent fields in this phase caused avoidable line transfers, and the tested layout reduced those transfers while preserving results. It does not establish a universal speedup, a protocol bug, or a remedy for every coherence hotspot.

Common pitfall

Declaring success from a faster single run while instruction counts, thread placement or the amount of useful work changed.

Interview

Propose a counterfactual experiment and two controls. Say what evidence would disprove your false-sharing hypothesis.

Check yourself If padding lowers transfers but runtime is unchanged, was the traffic hypothesis necessarily wrong?

No. The transfers may not have been on the dominant critical path. The traffic result and overall performance result answer different questions.

Related topics

  • Shared course model

  • Classify the sharing relationship

Previous

77 / 167

Next: Directory Capacity and Sharers

Up next

Up nextDirectory Capacity and Sharers

Sign in to save progress

Practice this lessonReport an error

See also

  • True Versus False Sharing
  • Counting Coherence Traffic