Memory Architecture

MSHR

Miss Status Holding Register

문제

초기 Blocking cache는 miss가 발생하면 miss가 하위 계층에서 채워질 때까지 캐시 전체가 잠김
=> miss를 처리하는 데 필요한 모든 상태를 별도의 작은 register에 저장하고 다음 일을 이어나가자

Miss의 3가지 종류

• Primary miss: 해당 블록에 대한 최초 miss. 비어 있는 MSHR을 하나 allocate하고, 하위 계층으로 fetch 요청을 한 번 보냄.
• Secondary miss: 이미 fetch가 진행 중인 블록(MSHR에 이미 등록된 주소)에 대한 후속 miss. 새 요청을 보내지 않고, 기존 MSHR 안에 target(subentry)만 추가.
  • request coalescing/merging으로, 중복 메모리 트래픽을 제거하는 효과입니다.
• Structural-stall miss: 빈 MSHR이 없거나(전체 소진), 매칭된 MSHR 안에 빈 target 슬롯이 없을 때. 이때 비로소 캐시가 stall
  • MSHR 개수가 MLP(Memory Level Parallelism)의 물리적 상한이 되는 지점

MSHR 구조

MSHR entry의 최대 개수 -> 동시에 처리 가능한 miss의 최대 개수 -> 지속 가능한 메모리 대역폭을 직접 결정하는 파라미터

MSHR이 부족 → N_outstanding 상한 → 독립적 miss들이 겹치지 못하고 직렬화 → 각 load가 오래 걸림 → 그 load들이 ROB head를 오래 점유 → ROB full → dispatch stall

Re-order buffer

• ROB = in-flight 명령어를 프로그램 순서로 담는 큐. 실행은 비순차(OoO)로 하되, commit(retire)은 head에서 순서대로만 한다.
• head가 미완료 명령어에 막히면 새 명령어를 window에 못 넣음 → window full → dispatch stall. outstanding load가 head를 막는 게 메모리 지연이 코어를 멈추는 경로
• 따라서 window 크기가 “동시에 노출 가능한 독립 메모리 요청 수”를 좌우함 → MLP의 상한을 MSHR과 함께 결정. Ramulator에서 memory 병목을 볼 땐 inst_window_depth(ROB)와 llc_num_mshr_per_core(MSHR)를 같이 봐야해