Hyper-Threading과 SMT: 논리 CPU·공유 자원·성능 측정

Intel Hyper-Threading은 Simultaneous Multithreading(SMT)의 Intel 브랜드다. 지원하는 CPU에서는 physical core 하나가 보통 두 개의 logical processor로 보인다. 두 logical processor는 각각 architecture state를 가지지만 execution unit, cache와 bus 같은 core resource 일부를 공유한다. Physical core가 두 개로 늘어나는 기술은 아니다.

Physical core와 logical CPU를 구분한다

Operating system scheduler는 각 logical processor를 CPU 하나처럼 다룬다. Intel 문서에 따르면 Hyper-Threading이 활성화된 core의 두 logical processor는 general-purpose register와 control register 같은 architecture state를 각자 갖는다. 반면 cache, execution unit와 bus 등의 resource는 공유된다.

단위	의미
Socket	Mainboard에 장착된 processor package
Physical core	실제 instruction을 실행하는 core
Logical CPU	Scheduler에 노출되는 hardware thread
SMT sibling	같은 physical core의 resource를 공유하는 logical CPU

Intel HT는 일반적으로 core당 두 thread를 뜻하지만 SMT라는 개념 전체가 언제나 2-way인 것은 아니다. Architecture와 product별 thread 수, 지원 여부와 활성 상태를 확인해야 한다.

SMT는 core의 빈 실행 기회를 활용한다

한 thread가 cache miss, branch recovery나 dependency 때문에 일부 execution resource를 쓰지 못할 때 sibling thread의 instruction이 그 빈 slot을 사용할 수 있다. 그래서 한 요청의 latency보다 여러 작업의 전체 throughput이 좋아지는 경우가 많다.

하지만 두 thread가 같은 resource를 많이 요구하면 경쟁한다.

• 같은 execution unit를 집중적으로 사용하는 compute workload
• L1·L2 cache capacity와 memory bandwidth를 많이 쓰는 workload
• branch predictor와 frontend pressure가 큰 workload
• tail latency가 중요한 latency-sensitive service

이 경우 성능 향상이 작거나 오히려 p99 latency가 나빠질 수 있다. “logical CPU가 두 배니 성능도 두 배”라는 계산은 성립하지 않는다.

Linux에서 topology를 확인한다

lscpu -e=CPU,CORE,SOCKET,NODE,ONLINE

CPU가 다르지만 CORE와 SOCKET이 같다면 같은 physical core에 속한 logical CPU일 수 있다. Kernel이 제공하는 sysfs에서도 sibling 관계를 확인할 수 있다.

cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
cat /sys/devices/system/cpu/cpu0/topology/core_id
cat /sys/devices/system/cpu/cpu0/topology/physical_package_id

Virtual machine이나 container에서는 host topology가 가려지거나 vCPU mapping이 달라질 수 있다. lscpu 출력의 logical CPU 수를 physical core 수로 그대로 해석하지 말고 cloud instance 문서와 hypervisor topology도 확인한다.

Python sleep 예제는 HT 성능 증거가 아니다

threading.Thread에서 여러 thread가 sleep하는 예제는 I/O waiting 동안 다른 작업을 진행하는 concurrency를 보여 준다. CPU execution resource를 두 sibling이 어떻게 공유하는지는 측정하지 않는다. 또한 Python runtime과 GIL, native extension 사용 여부가 CPU-bound thread 동작에 영향을 준다.

HT 효과를 보려면 실제 workload나 대표 benchmark를 사용해야 한다. Network waiting이 대부분인 예제를 근거로 CPU throughput이 늘었다고 결론 내릴 수 없다.

비교 실험은 조건을 고정한다

Firmware에서 SMT를 켜고 끄는 작업은 reboot와 서비스 영향이 있으므로 별도 test system에서 수행한다. 운영 변경 전에 다음 조건을 고정한다.

1. 같은 CPU frequency policy, NUMA placement와 memory capacity를 사용한다.
2. 같은 dataset, concurrency, warm-up과 측정 시간을 사용한다.
3. SMT on·off에서 worker 수를 physical core 기준과 logical CPU 기준으로 각각 비교한다.
4. 평균뿐 아니라 throughput, p50·p95·p99 latency와 maximum을 기록한다.
5. CPU utilization, instruction per cycle, cache miss, memory bandwidth와 power를 함께 본다.

SMT를 끄지 않고 placement 영향만 볼 때는 sibling pair와 서로 다른 core에 thread를 pinning한 실험을 추가할 수 있다. 다만 taskset 배치 비교는 SMT on·off 전체 효과와 같은 실험이 아니다.

Scheduler 숫자는 capacity 숫자와 같지 않다

Logical CPU 수를 그대로 application worker 수로 쓰면 shared resource 경쟁을 놓칠 수 있다. CPU-bound worker는 physical core 수 근처에서 최적점이 나올 수 있고, memory·I/O stall이 많은 workload는 더 많은 worker가 유리할 수 있다.

Container의 Kubernetes CPU 1도 node가 physical host인지 VM인지에 따라 physical core 또는 vCPU 시간 기준이다. SMT-enabled bare-metal node에서는 scheduler가 logical CPU를 allocatable CPU로 볼 수 있다. Exclusive CPU가 필요한 workload는 CPU Manager policy와 topology를 별도로 확인해야 한다.

CPU와 memory hierarchy의 기본 관계는 CPU와 메모리 차이에 정리했다.

SMT 보안은 구체적인 공격 경로로 판단한다

Sibling thread는 L1 cache와 일부 prediction·execution resource를 공유하므로 cross-thread side channel의 공격 표면이 될 수 있다. Linux kernel 문서는 MDS와 L1TF를 cross-HT attack의 예로 들며, core scheduling은 일부 공격을 줄일 수 있지만 모든 cross-thread attack을 막는 것은 아니라고 설명한다.

Meltdown이나 Spectre라는 이름만 보고 “HT를 끄면 모두 해결된다” 또는 “HT와 무관하다”고 단정하면 안 된다. CPU model, microcode, kernel mitigation, workload trust boundary와 virtualization 구성을 함께 본다. Multi-tenant 환경처럼 sibling에서 서로 신뢰하지 않는 code가 실행될 수 있다면 더 엄격한 판단이 필요하다.

현재 Linux의 취약점과 완화 상태는 sysfs에서 확인할 수 있다.

grep . /sys/devices/system/cpu/vulnerabilities/*

출력을 vendor·distribution advisory와 대조한 뒤 SMT disable, core scheduling, workload isolation 중 어떤 조합이 필요한지 정한다. SMT disable은 cross-HT attack에 가장 강한 경계가 될 수 있지만 logical CPU capacity와 throughput 손실도 측정해야 한다. CPU 취약점별 차이는 Meltdown·Spectre와 완화책에서 이어서 볼 수 있다.

언제 효과가 있을까

SMT의 이점이 기대되는 경우는 한 thread가 core resource를 모두 쓰지 못하고 자주 기다리는 throughput-oriented workload다. 반대로 이미 execution unit, cache나 memory bandwidth를 포화시키는 workload에서는 sibling이 경쟁만 늘릴 수 있다.

결론은 workload 특성만으로 미리 확정하지 않는다. 같은 보안 경계와 같은 부하에서 on·off 또는 sibling placement를 비교한 결과로 판단한다. 특히 server에서는 처리량 증가와 tail latency 악화를 함께 보지 않으면 사용자 경험의 손실을 놓칠 수 있다.

핵심 정리

Hyper-Threading은 한 physical core를 두 logical processor로 노출하는 Intel의 SMT 구현이다. Architecture state는 분리되지만 여러 core resource를 공유하므로 성능은 workload에 따라 좋아지거나 나빠질 수 있다. Topology를 확인하고 throughput·tail latency·hardware counter를 함께 측정하며, 보안은 구체적인 cross-thread vulnerability와 trust boundary로 판단해야 한다.

참고 자료

• Intel: Hyper-Threading Technology
• Linux kernel: CPU topology via sysfs
• Linux kernel: Core Scheduling
• Linux kernel: Attack Vector Controls
• Linux kernel: Spectre Side Channels