리눅스가 2002년의 유휴 상태 우회 코드를 삭제하자 AMD Zen 처리량이 최대 14배 증가했다

2002년 리눅스 커널에 ACPI 지원이 추가되었을 때 — Andy Grover가 작성하고 Linus Torvalds가 커밋한 — 여기에는 '더미 대기 작업(dummy wait op)'이 포함되어 있었다. 이는 시스템이 아무 목적 없이 데이터를 읽어, CPU가 STPCLK# 명령으로 완전히 정지할 수 있을 때까지 다음 명령을 지연시키는 것이었다. 이는 초창기에 일부 칩셋이 예상대로 유휴 상태에 진입하지 않으려 했을 때 전력 절감과 호환성을 확보해 주었다.

20년 후 AMD 엔지니어 Prateek Nayak은 'Zen 마이크로아키텍처 기반 프로세서에 대해 더미 대기를 건너뛰는' 커널 패치를 제출했다. 현대 Zen 칩은 그런 자극이 필요 없으며, 명령 기반 샘플링(instruction-based sampling)을 이용한 테스트에서 더미 작업이 여전히 상당한 시간을 소모하고 있었고 커널이 이를 C-state 체류 시간으로 잘못 계산하고 있음이 드러났다. 그 모든 저부하 작업을 보고 CPU는 스스로 더 깊고 느린 C-state로 진입했고, 그 다음 깨어나는 데 더 오래 걸렸다 — 이는 바쁜 상태와 유휴 상태를 끊임없이 오가는 작업에 악영향을 주었다.

측정 결과는 극적이었다. 듀얼 소켓 Zen3 시스템에서의 tbench 실행에서 패치된 커널은 기준 커널 대비 최소 MB/s 처리량이 1,390% 증가하고 평균 MB/s가 51% 증가했으며, 이는 C2 절전 상태를 완전히 비활성화한 결과에 가까웠다.

인텔 시스템은 MWAIT 기반 유휴 메커니즘 덕분에 10년 동안 이 레거시 저주를 피해 왔으며, 인텔의 Dave Hansen은 더미 대기를 인텔 시스템으로 제한하는 긴급 패치를 제출했다 — 인텔 시스템에서는 '원격으로 현대적인' 기계에 영향을 주지 않을 것이기 때문이다 — 그리고 독자들에게 더 현대적인 유휴 메커니즘으로 이동할 것을 촉구하는 주석을 덧붙였다. 제때 제출된 이 수정은 다음 주에 출시될 리눅스 6.0 커널에 반영될 수 있었다.

2002년의 무의미한 읽기 작업이 전력 관리에 의해 가벼운 부하의 증거로 잘못 해석되어 Zen 코어를 깊은 잠에 빠뜨렸다 — 이를 삭제하자 최소 처리량이 1,390% 증가했다.

진단이 핵심이다. 명령 기반 샘플링은 낭비된 시간이 건강한 수면으로 잘못 분류되고 있음을 밝혀냈고, 이로써 전력 관리 회계 버그가 눈에 보이는 성능 절벽으로 바뀌었다.

이 수정은 분기 하나의 비용이 든다 — Zen에서 더미 대기를 건너뛰는 것 — 그러나 최소 처리량을 14배 회복하며, 이는 실제 작업의 어떤 최적화로도 거의 달성할 수 없는 비율이다.

이것은 기술 부채의 살아있는 표본이다. 2002년 칩셋을 위해 추가된 코드가 아무것도 실패하지 않았기 때문에 20년과 여러 CPU 세대를 거쳐 살아남았고, 다만 느려졌을 뿐이다.

호환성 보조 코드는 그것이 지원하는 하드웨어보다 오래 산다. 누군가 새로운 실리콘에 대해 재검토하지 않는 한, 20년 된 무의미한 작업이 칩 문제처럼 보이는 보이지 않는 세금이 될 수 있다.

Nayak의 Zen 패치와 더미 대기를 인텔 시스템으로 제한하는 Hansen의 긴급 후속 패치가 2022년 9월 말에 제출되어, Torvalds가 다음 주에 출시할 것으로 예상한 리눅스 6.0 커널에서 검토될 수 있는 시기에 맞춰졌다. 인텔의 패치는 또한 현대적인 유휴 메커니즘으로의 이전을 장려하는 주석을 추가했다. Ars Technica는 패치가 적용된 후 AMD 시스템에 잔여 문제가 없었다고 보도했다.