Arm CPU에서 TSO 메모리 모델 지원 (2024)

Source: Hacker News

작성자: Jonathan Corbet
2024년 4월 26일

소개

CPU 수준에서 메모리 모델은 프로세서가 메모리 연산을 재배열할 수 있는 자유도의 양을 포함한 여러 사항을 설명합니다. 저수준 코드가 메모리 모델을 고려하지 않으면 불쾌한 놀라움이 뒤따를 가능성이 높습니다. 당연히 서로 다른 CPU는 서로 다른 메모리 모델을 제공하므로 특정 유형의 동시성 소프트웨어 이식성이 복잡해집니다. 이를 좀 더 쉽게 만들기 위해 일부 Arm CPU는 x86 메모리 모델을 에뮬레이션하는 기능을 제공하지만, 해당 기능을 커널에 적용하려는 시도는 반대에 부딪히고 있습니다.

CPU 설계자는 성능을 향상시키기 위해 가능한 모든 일을 합니다. 메모리 접근과 관련해서는 “모든 것”이 캐시 작업, 명령어를 순서대로 실행하지 않기, 여러 작업을 하나로 결합하기 등을 포함할 수 있습니다. 이러한 최적화는 고립된 단일 CPU에는 영향을 주지 않지만, 다른 CPU에게 메모리 연산이 예상치 못한 순서로 보이게 만들 수 있습니다. 시스템의 다른 곳에서 실행되는 부주의한 소프트웨어는 코드에서 읽을 수 있는 순서와 다른 순서로 메모리 연산을 볼 수 있습니다; 이 기사는 문제가 발생할 수 있는 간단한 시나리오를 설명하고, 이 락‑프리 알고리즘 시리즈는 메모리 순서와 관련된 문제를 피하기 위해 사용할 수 있는 몇 가지 기법을 자세히 보여줍니다.

x86 Total Store Ordering (TSO)

x86 아키텍처는 total store ordering(TSO)이라고 알려진 모델을 구현합니다. 이 모델은 쓰기(스토어)가 실행된 순서대로 모든 CPU에 보이도록 보장합니다. 읽기도 재배열되지 않지만, 읽기와 쓰기 사이의 상대적인 순서는 보장되지 않습니다. TSO 아키텍처용으로 작성된 코드는 많은 경우에 연산 순서를 강제하기 위해 필요했던 비용이 큰 배리어 명령어의 사용을 생략할 수 있습니다.

Source: …

Arm 메모리 모델

Arm 메모리 모델은 오히려 더 약해서 CPU가 연산을 더 자유롭게 재배열할 수 있습니다. 이러한 설계의 장점은 구현이 더 단순하고, 순서 보장이 필요하지 않은 상황(대부분의 경우)에서 더 나은 성능을 낼 수 있다는 점입니다. 단점은 동시성 코드를 올바르게 작성하려면 약간 더 많은 주의가 필요하고, 더 엄격한 메모리 모델(예: TSO)을 기준으로 작성된 코드는 Arm CPU에서 실행될 때 (미묘할 수 있는) 버그가 발생한다는 것입니다.

약한 Arm 모델은 드물게 문제가 되지만, 문제가 발생하는 한 가지 상황이 있습니다: x86 프로세서 에뮬레이션. x86 에뮬레이터가 TSO 메모리 모델도 함께 에뮬레이트하지 않으면 동시성 코드는 대부분 실패합니다. 그러나 TSO를 에뮬레이트하려면 메모리 배리어를 삽입해야 하며, 이는 상당한 성능 저하를 초래합니다. 동시성 x86 코드의 한 종류인 게임은 Arm CPU에서 실행될 경우 이점을 얻을 수 있지만, 이상하게도 이러한 사용자들은 성능이나 정확성 중 어느 하나라도 부족한 상황에서 오크 무리와 마주치는 것을 꺼려합니다.

TSO on Arm

일부 Arm CPU 제조업체는 이 문제를 이해하고, Hector Martin이 이 패치 시리즈에서 설명한 바와 같이 프로세서에 TSO 메모리 모델을 구현했습니다. 일부 NVIDIA와 Fujitsu CPU는 항상 TSO로 동작하고; Apple의 CPU는 런타임에 활성화할 수 있는 옵션 기능으로 제공됩니다. Martin의 목적은 이 기능을 사용자 공간에서 확인하고 제어할 수 있게 하는 것입니다.

시리즈는 몇 가지 새로운 prctl() 동작을 추가하는 것으로 시작합니다:

• PR_GET_MEM_MODEL – CPU가 구현하고 있는 현재 메모리 모델을 반환합니다. 값은 PR_SET_MEM_MODEL_DEFAULT 또는 PR_SET_MEM_MODEL_TSO 중 하나일 수 있습니다.
• PR_SET_MEM_MODEL – 요청된 메모리 모델을 활성화하려 시도합니다. 반환 코드는 성공 여부를 나타내며, 커널은 요청보다 더 엄격한 모델을 선택할 수도 있습니다.
  • 항상 TSO인 CPU에서는 TSO 요청이 당연히 성공합니다.
  • Apple CPU에서는 TSO 요청이 적절한 CPU 비트를 설정합니다.
  • TSO를 지원하지 않는 CPU에서 TSO를 요청하면 실패합니다.

Martin은 이 코드가 새 것이 아니라고 언급합니다: “이 시리즈는 이미 downstream Asahi Linux 트리에서 한동안 양조되고 있었으며, 수천 명의 사용자에게 제공되고 있습니다.” 흥미롭게도, Zayd Qumsieh는 하루 전에 비슷한 패치 세트를 올렸지만, 그 버전은 Apple CPU에서 가상 머신으로 실행되는 Linux에만 해당 기능을 구현했습니다.

Apple CPU에서 더 빠른 게임을 기대하던 사람들에게는 안타깝게도 두 패치 세트 모두 커널의 Arm 아키텍처 코드 유지관리자들에게 인기가 없습니다.

• Will Deacon은 “강력한 반대”를 표명하며, 이 기능이 사용자‑공간 코드의 파편화를 초래할 것이라고 말했습니다. 개발자는 문제가 사라지는 것처럼 보이면 TSO 비트를 단순히 켤 것이고, 그 결과 다른 Arm CPU에서는 미묘한 방식으로 실패할 수 있는 코드를 만들게 될 것이라고 경고했습니다.
• Catalin Marinas는 이러한 구현 정의 기능을 제공하는 패치를 차단하겠다고 밝혔습니다.

Martin은 파편화가 문제가 될 가능성은 낮다고 반박하며, 일부 프로세서(Apple 포함)에서 지원하는 서로 다른 페이지 크기가 이러한 비호환성을 처리할 수 있는 예시라고 지적했습니다. 또한 지금까지는 에뮬레이터 외에 TSO 기능을 사용하려는 시도가 없었기 때문에 다른 소프트웨어에서 남용될 가능성도 낮다고 덧붙였습니다. 그는 이를 제외하는 것이 상황을 개선하지는 않을 것이라고 주장했습니다:

“여기에는 실용적인 논리가 있습니다: 우리가 이것을 필요로 하고, 거부되더라도 downstream에서 계속 배포될 것이기 때문에, 파편화 위험에 큰 차이가 있지 않을까요? 대부분의 Linux‑on‑Mac 사용자는 새로운 기능과 하드웨어 지원을 더 빨리 받기 위해 앞으로도 downstream 커널을 계속 사용할 가능성이 높습니다. 따라서 upstream에서 이를 허용하지 않는다고 해서 상황이 크게 바뀌지는 않을 것입니다.”

토론 및 대안

Landscape vis‑a‑vis being able to abuse this or not, it just makes our life harder by forcing us to carry more patches forever.

Deacon, though, [insisted](/ml/linux-kernel/20240419165826.GB4020@willie-the-truck/) that, once a feature like this is merged, it will find uses in other software “and we’ll be stuck supporting it”.

If this patch is not acceptable, it is time to think about alternatives.

* One is to, as Martin described, just keep it out‑of‑tree and ship it on the distributions that actually run on that hardware. A long history of addition by distributions can, at times, eventually ease a patch’s way past reluctant maintainers.  
* Another might be to just enable TSO unconditionally on Apple CPUs, but that comes with an overall performance penalty — about **9 %**, according to Martin.  
* A third possibility was [mentioned](/ml/linux-kernel/87zftoqn7u.wl-maz@kernel.org/) by Marc Zyngier, who suggested that virtual machines could be started with TSO enabled, making it available to applications running within while keeping the kernel out of the picture entirely.

이 논의는 쉽게 사라지지 않을 것 같습니다. 수년간 리눅스가 돋보였던 여러 이유 중 하나는 사용자가 하드웨어를 최대한 활용할 수 있게 하는 능력입니다; 유용한 하드웨어 기능을 지원하지 않는 것은 그 역사의 흐름에 반합니다. 그러나 이 기능이 악용될 가능성에 대한 우려도 오랜 경험에 기반하고 있습니다. 이번 경우는 개발 커뮤니티가 오랜 역사의 또 다른 부분을 반복하여, 필요한 기능을 지원 가능한 방식으로 제공할 수 있는 해결책을 찾아야 한다는 것을 의미합니다.

색인

• Kernel / Architectures/Arm
• Kernel / Memory model

댓글을 달려면