The asker is building a single-producer/single-consumer (SPSC) queue and wants to understand which shared microarchitectural resources a "busy reader" — a consumer that spins reloading a cache line — can saturate. The concern is subtle false sharing: even when producer and consumer touch logically distinct lines, they may contend on hidden structures the PMU doesn't expose cleanly.

Why it's hard: The memory subsystem on modern x86 is a stack of queues, buffers and trackers, many of which Intel/AMD only partially document. A spinning reader doesn't just "read memory" — it pushes traffic through:

• Line Fill Buffers (LFBs) on the core — typically ~10–12 entries. Every outstanding L1 miss occupies one until the line returns.
• L2 Super-Queue / XQ — tracks misses heading to the L3/ring.
• Ring/mesh interconnect slots — a request crosses tiles to reach the LLC slice and the home agent.
• LLC slice MSHRs and the CHA (Caching/Home Agent) snoop filter — the uncore tracker that arbitrates coherence.
• Memory controller queues if the line escapes the LLC.

A "busy reader" hitting the same line repeatedly mostly stays in L1 once warm, costing nothing. But the moment the producer writes — invalidating the line — the reader's next load takes a long round trip through the CHA to fetch the modified copy from the producer's core. That coherence handshake is the real cost, and the consumer's pending miss occupies an LFB the entire time.

Direction toward an answer:

• Distinguish throughput congestion (LFBs full → backpressure on loads) from coherence congestion (CHA snoop pipelines, directory updates).
• Look at PMU events like L1D_PEND_MISS.FB_FULL, OFFCORE_REQUESTS_BUFFER.SQ_FULL, and uncore UNC_CHA_TOR_OCCUPANCY / UNC_CHA_REQUESTS. These do exist but you need the right CPU's uncore reference (Intel's Uncore Performance Monitoring Reference Manual per generation — Skylake-SP, Ice Lake-SP, Sapphire Rapids each differ).
• For tricky false sharing, the giveaway is high MEM_LOAD_L3_MISS_RETIRED.REMOTE_HITM or ...LOCAL_HITM — a load that found the line dirty in another core's cache.

Gotchas: a single spinner on one line looks cheap because the LFB coalesces. Multiple readers, or a reader that touches neighboring lines (adjacent-line prefetcher pulls them in), can quietly cause snoops to lines the producer thought it owned exclusively. Padding to two cache lines (128B) — not one — is the conservative answer on Intel because of that prefetcher.