DRAM & Memory Design · All levels
Memory Controller Scheduling: Tricky Q&A
Senior interview and review questions for Memory Controller Scheduling.
Section Q&A bank
Use these drills after completing all topics in Memory Controller Scheduling. Answer with workload context, mechanism proof, artifact, owner, and release decision.
Why does increasing request queue depth sometimes improve throughput but hurt P99 latency?
diagram
[INT][DRAM][CONTROLLER-SCHEDULING]
Q: Why does increasing request queue depth sometimes improve throughput but hurt P99 latency?
A:
Deeper queues expose more reordering opportunities, allowing the scheduler to find bank-parallel and row-hit-friendly work that raises bandwidth. But the same depth increases waiting time variance, especially for requests that conflict with dominant hot rows or low-priority classes. Without aging and QoS limits, deep queues can amplify head-of-line and starvation effects, inflating tail latency even while average throughput improves.
FOLLOW-UP TRAP: Assuming queue depth is a monotonic performance win for both bandwidth and latency.When can FR-FCFS become harmful despite strong row-hit improvements?
diagram
[INT][DRAM][CONTROLLER-SCHEDULING]
Q: When can FR-FCFS become harmful despite strong row-hit improvements?
A:
FR-FCFS can over-favor requests that are immediately ready (often row hits), repeatedly delaying row-miss or lower-locality flows. In mixed workloads this can violate fairness and service-level targets, especially for traffic with sparse locality but strict latency needs. The fix is not discarding FR-FCFS, but bounding it with aging, class-aware arbitration, and page-policy controls.
FOLLOW-UP TRAP: Treating row-hit maximization as equivalent to optimal system QoS.How should a controller choose between open-page and close-page behavior in practice?
diagram
[INT][DRAM][CONTROLLER-SCHEDULING]
Q: How should a controller choose between open-page and close-page behavior in practice?
A:
It should adapt per bank using observed locality and contention: keep rows open when near-term reuse probability is high, and close sooner when conflict likelihood or contention is high. Static global policy misses workload phase shifts and can either waste row-hit opportunity or create excessive precharge/activate churn. Adaptive page policy is effective only if tied to real command timing limits and fairness controls.
FOLLOW-UP TRAP: Using one fixed page policy for all traffic and all banks.Why can refresh policy break real-time latency even when average bandwidth loss looks small?
diagram
[INT][DRAM][CONTROLLER-SCHEDULING]
Q: Why can refresh policy break real-time latency even when average bandwidth loss looks small?
A:
Refresh interference is bursty and timing-sensitive, not uniformly distributed. Averages can hide clustered refresh events that coincide with critical traffic windows, causing short but severe latency spikes. Real-time validation must inspect tail distributions and temporal alignment of refresh blocking with high-priority demand, not just aggregate throughput loss.
FOLLOW-UP TRAP: Relying on mean bandwidth impact to claim refresh has negligible QoS effect.Q&A drill guide
diagram
WORKLOAD -> DRAM SYMPTOM -> TIMING/QUEUE METRIC -> ROOT CAUSE -> FIX -> REGRESSIONSketch while answering
diagram
CONTROLLER SCHEDULING LOOP
request queues -> row-policy + priority -> command issue -> bank state updateKey takeaways
Always tie controller and PHY counter shifts to application latency and throughput outcomes.
Lock firmware timing profile, thermal condition, and DIMM state before comparing DRAM captures.
Common pitfalls
Chasing peak bandwidth while ignoring p99 latency and fairness tails.
Changing timing guardbands without separating SI noise from scheduling issues.
Declaring closure without reliability gates, fault injection, and regression replay.