Linux가 Cache Aware Scheduling 관련 AMD Ryzen AI 9 HX 370의 회귀 현상을 수정
LINUX KERNEL
지난 8월로 거슬러 올라가는 버그 리포트를 통해, Cache Aware Scheduling이 AMD Ryzen AI 9 HX 370에서 문제를 일으킨 것으로 밝혀졌습니다. 이 문제를 보고한 사용자는 Gentoo를 실행하는 과정에서 LLVM Clang을 사용하여 전체 링크 시간 최적화(LTO)가 적용된 코드 컴파일 워크로드를 수행했을 때, 효율성 코어인 'little' 코어에서 시작된 프로세스들이 더 큰 성능 코어로 이동하지 않는다는 것을 발견했습니다. 특히 Clang LTO 작업의 경우, 작은 코어에 자주 고정되는 현상이 발생했습니다. Ryzen AI 9 HX 370은 네 개의 Zen 5 코어와 여덟 개의 Zen 5C 코어로 구성된 총 12개의 코어를 가지고 있습니다.
이 버그 리포트는 Cache Aware Scheduling이 적용된 최신 Linux 커널에서, 적용되지 않은 경우보다 Clang LTO 성능이 저하되었음을 성공적으로 입증했습니다. 또한, 밀도가 높은 Zen 5C 코어는 약 5.1GHz가 아닌 최대 3.3GHz까지만 작동하며, 더 큰 코어에 비해 캐시 크기가 절반이라는 점도 문제가 되었습니다.
어제 Linux 커널에 패치가 병합되면서 이 문제는 해결되어야 합니다. 이제 Cache Aware Scheduling은 하이브리드 시스템에서 비대칭 패킹(asymmetric packing)을 존중하게 됩니다. 해당 패치는 다음과 같은 변경 사항을 설명합니다:
"AMD Ryzen AI HX 370에서 캐시 집약적인 Clang 전체-LTO 링크를 실행하는 과정에서 회귀 현상이 보고되었습니다. little 코어는 훨씬 낮은 주파수(5.1 GHz 대비 3.3 GHz)로 작동하며 L3 캐시도 절반(16 MB 대비 8 MB)만 가지고 있기 때문에, 이러한 작업을 little 코어 LLC에 고정하면 두 배의 손실이 발생하고, 전체-LTO 빌드는 cache-aware-scheduling 커널보다 극적으로 느려집니다.
비대칭 패킹과 캐시 인식 스케줄링은 상충되는 배치 전략을 표현합니다. 비대칭 패킹은 작업이 가장 높은 우선순위의 CPU에서 실행되기를 원하지만, 캐시 인식 스케줄링은 프로세스의 작업을 해당 LLC 내의 CPU 우선순위에 관계없이 하나의 LLC에 함께 위치시키기를 원합니다.
비대칭 패킹이 소스 CPU보다 더 높은 우선순위를 가진 유휴 코어로 작업을 마이그레이션하려고 할 때, 비대칭 패킹의 승리를 허용해야 합니다. 작업을 더 높은 성능을 가진 유휴 코어로 이동시키는 것이 캐시 공동 배치(cache co-location)를 하는 것보다 더 많은 성능 향상을 가져다줄 것입니다."
일반 및 활성 부하 분산(load balancing)을 위해 LLC 균형 맞추기(LLC balancing)보다 비대칭 패킹(asym packing)을 우선시합니다.
이 수정 사항은 일요일에 스케줄러 수정(scheduler fixes) 풀 리퀘스트를 통해 병합되었습니다. 버그 리포트의 주제로 인해 Ryzen AI 9 HX 370에 초점이 맞춰져 있지만, 이 캐시 인식 스케줄링(Cache Aware Scheduling) 수정 사항은 Zen 5/5C 코어 조합을 가진 다른 Ryzen SoC에도 도움을 줄 수 있습니다.