바쁜 DRAM에서 refresh를 미뤄도 되는 범위

DRAM이 바쁘게 데이터를 보내는 중 refresh 시각이 다가온다. 지금 멈추지 말고 요청이 줄어든 뒤 몰아서 처리하면 더 효율적일 것 같다. DDR4는 refresh를 조금 미루거나 당길 수 있지만 무제한 재정렬은 허용하지 않는다. Refresh Postponement의 핵심은 바쁜 구간을 피하면서도 갚아야 할 refresh 작업의 양과 마감 시간을 관리하는 데 있다.

tREFI는 refresh command를 평균적으로 얼마나 자주 보내야 하는지를 나타낸다. 모든 REF를 정확히 같은 간격에 고정할 필요는 없지만, 평균이라는 말이 개별 긴 공백을 무한히 허용한다는 뜻도 아니다. 저장된 모든 행을 정해진 시간 범위에서 관리해야 하므로 postpone와 pull-in에는 별도 한계가 있다.

미룬 작업은 없어지지 않는다

Alliance DDR4 데이터시트의 Refresh Command 설명과 그림 47·48은 1x mode에서 최대 여덟 refresh command의 postponement와 주변 REF 사이 최대 9×tREFI 간격을 설명한다. 2x·4x mode의 count와 interval 기준은 각각 따로 정의되어 있다. 다른 mode의 숫자를 섞어 쓰면 허용 간격이 달라진다.

문서의 TCASE≤85°C, 1x base tREFI=7.8μs를 사용하면 9×7.8μs=70.2μs다. 이 값은 해당 조건의 주변 refresh command 사이 제한을 계산한 것이며, 모든 셀을 70.2μs마다 전부 refresh한다는 의미가 아니다. 한 REF가 내부 refresh 주소 순서를 진행하고 전체 작업은 여러 REF로 이루어진다.

가상 controller가 7.8μs마다 하나의 refresh 작업을 예정했다고 생각하자. 예정 시점이 지나면 debt가 하나 늘고 실제 REF를 발행하면 하나 줄어드는 단순 모델을 사용할 수 있다. 바쁜 구간에 몇 번 미루면 debt가 쌓이고, 한가한 구간에서 그만큼 보충한다. 구현은 mode 전환·pull-in·전환 조건을 더 정확히 반영해야 하지만 “미룸은 비용 삭제가 아니다”라는 점을 확인하기에는 유용하다.

한 번에 갚을 때의 긴 멈춤

같은 제품 표의 1x tRFC minimum 350ns를 사용하면 여덟 REF의 동작 시간을 단순 합한 값은 2.8μs다. 각 command 사이 규칙을 만족하며 연속 배치한다고 가정한 minimum 작업량이다. refresh 전 모든 bank를 닫는 시간과 다른 운영 overhead는 포함하지 않았다.

바쁜 구간에서 350ns 멈춤을 여러 번 피했더라도 이후 2.8μs 수준의 작업량을 몰아 처리해야 할 수 있다. 새 요청이 바로 그 구간에 도착하면 큰 latency를 경험한다. postponed refresh가 throughput을 돕는 상황에서도 최대 대기시간이 나빠질 수 있는 이유다.

pull-in도 무한한 저축이 아니다. 문서는 1x mode에서 advance count의 한계를 정하고, 그보다 더 많은 refresh를 미리 보냈다고 해서 이후 정규 refresh 의무가 계속 감소하지 않음을 설명한다. 수십 번 미리 refresh하고 아주 오래 쉬는 전략은 허용되는 재정렬이 아니다.

refresh가 가능해지는 상태까지 포함하기

REF를 보내려면 해당 조건에서 모든 bank가 precharged이고 필요한 tRP 등을 만족해야 한다. debt count가 한계에 가까워졌는데 열린 행의 WRITE recovery가 남아 있다면 즉시 REF를 발행할 수 없다. 다음 마감까지의 slack에는 row 닫기와 명령 준비 시간도 들어가야 한다.

따라서 “REF를 지금 보낼 것인가”만 판단하는 정책보다 “언제까지 bank들을 REF 가능한 상태로 만들 것인가”를 포함하는 정책이 필요하다. 마감 직전에 모든 bank를 급하게 닫으면 locality를 크게 잃거나 중요한 요청을 오래 막을 수 있다. debt와 준비 시간을 함께 보면 이런 압력을 더 일찍 발견한다.

Postponement의 이득은 현재의 유용한 데이터 전달과 refresh 작업을 덜 충돌하게 배치하는 데 있다. 저장 정보를 덜 관리해도 된다는 기능이 아니다. 적용할 때는 mode·온도에 맞는 count 한계, 주변 REF 간격, 보충 작업량, bank 닫기 준비를 같은 시간선에서 검사하자. refresh를 미룬 횟수와 그로 인해 생기는 미래 대기시간을 함께 보고 결정해야 한다.