![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
현재 Linux symmetric multiprocessing (SMP) 커널(2.4 & 2.5 버전)은 Hyper-Threading(Hyper-Threading)을 지원하고 있고, 퍼포먼스 속도향상은 멀티쓰레드 밴치마크에서 입증되었다(참고자료).
이 글은 Linux SMP 커널에서 Hyper-Threading (HT)의 효과를 조사한 결과이다. Hyper-Threading은 인식하고 있는 Linux SMP 커널과 그렇지 않은 커널의 퍼포먼스를 비교했다. 이 테스트에 쓰인 시스템은 멀티쓰레딩이 가능한 싱글-CPU Xeon 이다. 벤치마크 범위는 스케쥴러, 저수준 커널 프리머티브, 파일 서버, 네트워크, 쓰레드 지원 등의 Hyper-Threading에 영향을 받을 수 있는 커널 내의 부분들이다.
Linux kernel 2.4.19의 결과는 Hyper-Threading 기술이 멀티쓰레드 애플리케이션을 30%나 향상시킬 수 있음을 보여주었다. Linux kernel 2.5.32에 이루어지고 있는 현재 작업은 51% 정도의 퍼포먼스 속도 향상을 가져왔다.
Intel의 Hyper-Threading Technology는 Intel NetBurst microarchitecture pipeline 내에서 리소스를 복제, 파티셔닝, 공유함으로서 한 개의 물리적 프로세서에 두 개의 논리적 프로세서를 존재할 수 있도록 한다.
복제된 리소스는 두 개의 쓰레드를 위해 리소스 카피들을 만든다 :
- 모든 CPU 당 아키텍쳐 상태
- 인스트럭션 포인터, 재명명 로직
- 작은 리소스들 (리턴 스택 프레디케이터, ITLB)
파티션 된 리소스들은 실행 쓰레드 사이에서 리소스들을 분리한다:
- 여러 버퍼들 (Re-Order Buffer, Load/Store Buffers, 큐(queues))
공유 리소스들은 두 개의 실행 쓰레드 사이에서 필요한 만큼 리소스들을 사용한다:
- Out-of-Order 실행 엔진
- 캐시
일반적으로 각각의 물리적 프로세서에는 서비스 쓰레드에 대한 하나의 프로세서 코어에 하나의 아키텍쳐 상태가 있다. HT를 이용하면 각각의 물리적 프로세서는 하나의 코어에 두 개의 아키텍쳐 상태를 갖게 되면서 물리적 프로세서는 서비스 쓰레드에 대해 두 개의 논리적 프로세서로 보인다. BIOS는 물리적 프로세서상에 있는 각각의 아키텍쳐 상태를 센다. Hyper-Threading 지원 OS는 물리적 프로세서를 사용하기 때문에 그러한 OS는 서비스 쓰레드에 대해 두 배 정도의 리소스를 갖게된다.
Xeon 프로세서는 범용 프로세서에서 Simultaneous Multi-Threading (SMT)를 구현한 첫 번째 프로세서이다. (참고자료) 하나의 물리적 프로세서에서 두 개의 쓰레드를 실행하는 목적을 달성하기 위해서, 프로세서는 다중 쓰레드 콘텍스트를 동시에 유지한다.
OS는 코드의 쓰레드를 각각의 논리적 프로세서에 코드 쓰레드를 스케쥴링하고 실행한다. 쓰레드가 실행될 때 관련 논리적 프로세서는 유휴 상태가 된다.
쓰레드가 논리적 프로세서(LP0)에 스케쥴링 및 실행될 때 Hyper-Threading 기술은 필요한 프로세서 리소스를 사용하여 쓰레드를 실행한다.
두 번째 쓰레드가 두 번째 논리적 프로세서(LP1)에서 스케쥴링 및 실행될 때 리소스들은 복제, 분리, 공유된다. 이는 두 번째 쓰레드를 실행하기 위해서이다. 각각의 프로세서는 쓰레드를 제어하고 처리하기 위해 파이프라인의 포인트마다 선택한다. 각각의 쓰레드가 끝나면 OS는 사용되지 않는 프로세서를 유휴상태가 되게 하여 실행 프로세스를 위한 리소스를 보유한다.
OS는 쓰레드들을 각각의 논리적 프로세서에 스케쥴링 및 실행하는데 듀얼 프로세서 또는 멀티 프로세서 시스템에 있는 것 처럼 실행된다. 시스템이 쓰레드들을 파이프라인으로 스케쥴링 할 때 두 개의 쓰레드들을 프로세스할 때 필요한 만큼 리소스들이 사용된다.
Linux kernel 2.4에서의 Hyper-Threading 지원
리눅스 커널에서, 두 개의 가상 프로세서를 가진 Hyper-Threading 프로세서는 한 쌍의 물리적
프로세서로 취급된다. 결과적으로 SMP를 핸들하는 스케쥴러는 하이퍼 쓰레딩도 핸들할 수 있어야한다. Linux
kernel 2.4.x에서의 Hyper-Threading 지원은 2.4.17 부터 시작하며 다음과 같은
기능이 포함된다:
- 128-byte lock alignment
- Spin-wait loop optimization
- Non-execution based delay loops
- Detection of Hyper-Threading enabled processor and starting the logical processor as if machine was SMP
- Serialization in MTRR and Microcode Update driver as they affect shared state
- Optimization to scheduler when system is idle to prioritize scheduling on a physical processor before scheduling on logical processor
- Offset user stack to avoid 64K aliasing
리눅스 커널에서 Hyper-Threading 효과를 측정하기 위해서 Hyper-Threading이 되는
Intel Xeon 프로세서를 포함하고 있는 시스템상에서 커널 벤치마크의 퍼포먼스를 측정했다. 하드웨어는
하나의 CPU에 1.6 GHz Xeon MP 프로세서이고 SMT, 2.5 GB RAM, 두 개의 9.2
GB SCSI 디스크 드라이브를 갖고있다. 측정되고 있는 커널은 2.4.19 버전이고 SMP가 가능하도록
설정 및 구현되었다. 커널의 Hyper-Threading 지원은 Hyper-Threading에 대해서는
acpismp=force 부트 옵션을 비 Hyper-Threading에 대해서는
noht 를 지정했다. Hyper-Threading 지원이 된다는 것은 cat
/proc/cpuinfo 명령어를 사용하여 볼 수 있다. 두 개의 프로세서(processor
0과 processor 1)을 보여준다. 비 Hyper-Threading 지원의 경우 데이터는 processor
0에 대해서만 디스플레이된다.
리눅스 커널 퍼포먼스를 측정하기 위해서 다섯 개의 벤치마크가 사용되었다. LMbench, AIM Benchmark Suite IX (AIM9), chat, dbench, tbench. LMbench 벤치마크는 다양한 리눅스 애플리케이션 프로그래밍 인터페이스(API)를 기록한다. AIM9 벤치마크는 사용자 애플리케이션 워크로드를 측정한다. chat 벤치마크는 클라이언트-서버 워크로드이다. dbench 벤치마크는 파일 서버 워크로드이며 tbench는 TCP 워크로드 이다. Chat, dbench, tbench는 멀티쓰레드 벤치마크이지만 다른 벤치마크들은 싱글 쓰레드 벤치마크이다.
Linux API에서의 Hyper-Threading 효과
Linux API에서의 Hyper-Threading 효과는 LMbench에 의해 측정된다. 이것은 대역폭과 레이턴시 측정을 포함하고 있는 마이크로벤치마크이다. 이들 중 파일 읽기, 메모리 카피 (bcopy), 메모리 일기/쓰기 (레이턴시), pipe, 콘텍스트 변환, 네트워킹, 파일시스템 생성과 삭제, 프로세스 생성, 신호 처리, 프로세서 시계 레이턴시 등이 캐싱된다. LMbench는 다음의 커널 컴포넌트를 검사한다. 스케쥴러, 프로세스 관리, 통신, 네트워킹, 메모리 맵, 파일시스템. 저수준 커널 프리머티브는 하드웨어 기능과 퍼포먼스에 대한 훌륭한 지침이된다.
Hyper-Threading의 효과를 연구하기 위해서 메시지 제어 시간을 측정하는 레이턴시 측정에 중점을 두었다. 레이턴시 숫자는 작동 당 마이크로초(microseconds)로 보고된다.
표 1은 LMbench에서 테스트되는 커널 기능의 일부 리스트이다. 각각의 데이터 포인트는 세 가지 실행에 대한 평균이고 데이터는 같은 테스트 환경이 되어야 할 때 반복가능함을 확인하는 전제 하에 테스트되었다. 일반적으로 싱글 쓰레드처럼 실행하는 기능의 경우 하이퍼 쓰레드와 비 하이퍼 쓰레드 사이에는 퍼포먼스 차이가 없다. 하지만 두 개의 쓰레드가 실행되어야 하는 테스트 경우 Hyper-Threading이 레이턴시 시간을 줄였다. SMP 커널은 2419s로 표시된다. 커널이 Hyper-Threading 지원 없이 설정되었다면 2419s-noht로 표시된다. Hyper-Threading 지원으로 커널은 2419s-ht으로 리스팅된다.
표 1. Linux API에서의 Hyper-Threading 효과
| Kernel function | 2419s-noht | 2419s-ht | Speed-up |
| Simple syscall | 1.10 | 1.10 | 0% |
| Simple read | 1.49 | 1.49 | 0% |
| Simple write | 1.40 | 1.40 | 0% |
| Simple stat | 5.12 | 5.14 | 0% |
| Simple fstat | 1.50 | 1.50 | 0% |
| Simple open/close | 7.38 | 7.38 | 0% |
| Select on 10 fd's | 5.41 | 5.41 | 0% |
| Select on 10 tcp fd's | 5.69 | 5.70 | 0% |
| Signal handler installation | 1.56 | 1.55 | 0% |
| Signal handler overhead | 4.29 | 4.27 | 0% |
| Pipe latency | 11.16 | 11.31 | -1% |
| Process fork+exit | 190.75 | 198.84 | -4% |
| Process fork+execve | 581.55 | 617.11 | -6% |
| Process fork+/bin/sh -c | 3051.28 | 3118.08 | -2% |
| 주: 데이터는 마이크로초이다. 적을 수록 좋다.. | |||
파이프 레이턴시 테스트는 유닉스 파이프를 통해 통신하는 두 개의 프로세스를 사용하여 소켓을 통한 프로세스간 통신 레이턴시를 측정한다. 벤치마크는 두 개의 프로세스 사이에서 토큰을 앞뒤로 전달한다.
세 개의 프로세스 테스트에는 리눅스에서 프로세스 생성과 실행이 포함되어 있다. 목적은 기본적인 제어 쓰레드를 만드는데 걸리는 시간을 측정하는 것이다. fork+exit 프로세스 테스트의 경우 데이터는 하나의 프로세스를 두 개의 동일한 카피로 나누고 한 개를 종료하는데 걸리는 리이턴시 시간을 나타낸다. 이것은 새로운 프로세스가 만들어지는 방법이지만 두 프로세스가 같은 일을 하기 때문에 유용하지는 않다. 이 테스트에서 Hyper-Threading은 4%의 감소를 보였다.
fork+execve 프로세스에서 데이터는 새로운 프로세스를 만들고 그 새로운 프로세스가 새로운 프로그램을 실행시키는데 걸리는 시간을 나타낸다. 이것은 모든 쉘의 내부 루프이다. 이 테스트는 Hyper-Threading 덕에 6%의 감소를 보였다.
fork+/bin/sh -c 프로세스 테스트에서 데이터는 새로운 프로세스를 만들고 그 새로운 프로세스가 새로운 프로그램을 실행하는 데 걸리는 시간을 나타낸다. 이때 시스템 쉘에게 프로그램을 찾아 실행하도록 명령한다. 이것은 C 라이브러리 인터페이스 호출 시스템이 구현되는 방법이다. 이 호출은 가장 일반적이며 가장 비싸다. Hyper-Threading의 경우 이 테스트는 비 Hyper-Threading과 비교하여 2% 더 느리게 실행된다.
싱글 유저 애플리케이션 워크로드의 경우 Hyper-Threading의 효과
AIM9 벤치마크는 하드웨어와 OS 퍼포먼스를 측정하도록 설계된 싱글 유저 워크로드이다. 결과는 표 2에 나와있다. 이 벤치마크에서 대부분의 테스트는 sync 파일 작동과 정수 Sieves를 제외하고는 Hyper-Threading과 비 Hyper-Threading에서 똑같이 수행되었다. Sync Random Disk Writes, Sync Sequential Disk Writes, Sync Disk Copies 작동은 Hyper-Threading에서 거의 35% 정도 느렸다. 반면 Hyper-Threading은 정수 Sieves의 경우 비 Hyper-Threading보다 60% 향상을 보였다.
표 2. AIM9 워크로드에서 Hyper-Threading의 효과
| 2419s-noht | 2419s-ht | Speed-up | ||
| add_double | Thousand Double Precision Additions per second | 638361 | 637724 | 0% |
| add_float | Thousand Single Precision Additions per second | 638400 | 637762 | 0% |
| add_long | Thousand Long Integer Additions per second | 1479041 | 1479041 | 0% |
| add_int | Thousand Integer Additions per second | 1483549 | 1491017 | 1% |
| add_short | Thousand Short Integer Additions per second | 1480800 | 1478400 | 0% |
| creat-clo | File Creations and Closes per second | 129100 | 139700 | 8% |
| page_test | System Allocations & Pages per second | 161330 | 161840 | 0% |
| brk_test | System Memory Allocations per second | 633466 | 635800 | 0% |
| jmp_test | Non-local gotos per second | 8666900 | 8694800 | 0% |
| signal_test | Signal Traps per second | 142300 | 142900 | 0% |
| exec_test | Program Loads per second | 387 | 387 | 0% |
| fork_test | Task Creations per second | 2365 | 2447 | 3% |
| link_test | Link/Unlink Pairs per second | 54142 | 59169 | 9% |
| disk_rr | Random Disk Reads (K) per second | 85758 | 89510 | 4% |
| disk_rw | Random Disk Writes (K) per second | 76800 | 78455 | 2% |
| disk_rd | Sequential Disk Reads (K) per second | 351904 | 356864 | 1% |
| disk_wrt | Sequential Disk Writes (K) per second | 154112 | 156359 | 1% |
| disk_cp | Disk Copies (K) per second | 104343 | 106283 | 2% |
| sync_disk_rw | Sync Random Disk Writes (K) per second | 239 | 155 | -35% |
| sync_disk_wrt | Sync Sequential Disk Writes (K) per second | 97 | 60 | -38% |
| sync_disk_cp | Sync Disk Copies (K) per second | 97 | 60 | -38% |
| disk_src | Directory Searches per second | 48915 | 48195 | -1% |
| div_double | Thousand Double Precision Divides per second | 37162 | 37202 | 0% |
| div_float | Thousand Single Precision Divides per second | 37125 | 37202 | 0% |
| div_long | Thousand Long Integer Divides per second | 27305 | 27360 | 0% |
| div_int | Thousand Integer Divides per second | 27305 | 27332 | 0% |
| div_short | Thousand Short Integer Divides per second | 27305 | 27360 | 0% |
| fun_cal | Function Calls (no arguments) per second | 30331268 | 30105600 | -1% |
| fun_cal1 | Function Calls (1 argument) per second | 112435200 | 112844800 | 0% |
| fun_cal2 | Function Calls (2 arguments) per second | 97587200 | 97843200 | 0% |
| fun_cal15 | Function Calls (15 arguments) per second | 44748800 | 44800000 | 0% |
| sieve | Integer Sieves per second | 15 | 24 | 60% |
| mul_double | Thousand Double Precision Multiplies per second | 456287 | 456743 | 0% |
| mul_float | Thousand Single Precision Multiplies per second | 456000 | 456743 | 0% |
| mul_long | Thousand Long Integer Multiplies per second | 167904 | 168168 | 0% |
| mul_int | Thousand Integer Multiplies per second | 167976 | 168216 | 0% |
| mul_short | Thousand Short Integer Multiplies per second | 155730 | 155910 | 0% |
| num_rtns_1 | Numeric Functions per second | 92740 | 92920 | 0% |
| trig_rtns | Trigonometric Functions per second | 404000 | 405000 | 0% |
| matrix_rtns | Point Transformations per second | 875140 | 891300 | 2% |
| array_rtns | Linear Systems Solved per second | 579 | 578 | 0% |
| string_rtns | String Manipulations per second | 2560 | 2564 | 0% |
| mem_rtns_1 | Dynamic Memory Operations per second | 982035 | 980019 | 0% |
| mem_rtns_2 | Block Memory Operations per second | 214590 | 215390 | 0% |
| sort_rtns_1 | Sort Operations per second | 481 | 472 | -2% |
| misc_rtns_1 | Auxiliary Loops per second | 7916 | 7864 | -1% |
| dir_rtns_1 | Directory Operations per second | 2002000 | 2001000 | 0% |
| shell_rtns_1 | Shell Scripts per second | 95 | 97 | 2% |
| shell_rtns_2 | Shell Scripts per second | 95 | 96 | 1% |
| shell_rtns_3 | Shell Scripts per second | 95 | 97 | 2% |
| series_1 | Series Evaluations per second | 3165270 | 3189630 | 1% |
| shared_memory | Shared Memory Operations per second | 174080 | 174220 | 0% |
| tcp_test | TCP/IP Messages per second | 65835 | 66231 | 1% |
| udp_test | UDP/IP DataGrams per second | 111880 | 112150 | 0% |
| fifo_test | FIFO Messages per second | 228920 | 228900 | 0% |
| stream_pipe | Stream Pipe Messages per second | 170210 | 171060 | 0% |
| dgram_pipe | DataGram Pipe Messages per second | 168310 | 170560 | 1% |
| pipe_cpy | Pipe Messages per second | 245090 | 243440 | -1% |
| ram_copy | Memory to Memory Copy per second | 490026708 | 492478668 | 1% |
리눅스 멀티쓰레드 애플리케이션 워크로드에서 Hyper-Threading 효과
리눅스 멀티쓰레드 애플리케이션에서 Hyper-Threading 효과를 측정하기 위해서 chat 벤치마크를 사용한다. 이 벤치마크에는 클라이언트와 서버가 포함된다. 클라이언트 측 벤치마크는 초당 전송된 메시지 수를 기록할 것이다. chat room의 수와 메시지 수는 워크로드를 제어할 것이다. 워크로드는 많은 쓰레드들과 CP/IP 연결을 만들고 많은 메시지들을 주고 받는다. 다음과 같은 디폴트 매개변수를 사용한다:
- chat room의 수 = 10
- 메시지 수 = 100
- 메시지 크기 = 100 bytes
- 사용자 수 = 20
기본적으로 각각의 chat room은 20명의 사용자를 갖고 있다. 총 10개의 chat room은 200명의 사용자를 갖게된다. chat room의 각 사용자들의 경우 클라이이언트는 서버와 연결한다. 200명의 사용자가 있으므로 서버에 200개의 연결을 갖고있다. 이제 chat room의 각 사용자(연결)의 경우 "보내기" 쓰레드와 "받기" 쓰레드가 만들어진다. 따라서 10개의 chat room 시나리오는 400 클라이언트 쓰레드와 400 서버 쓰레드를 만들게 된다. 총 800 쓰레드이다.
클라이언트의 "보내기" 쓰레드는 특정 수의 메시지를 서버에 보낸다. 10개의 chat room과 100개의 메시지의 경우 클라이언트는 20,000(10x20x100)개의 메시지를 보낸다. 서버의 "받기" 쓰레드는 그에 상응하는 메시지를 받는다. chat room 서버는 각각의 메시지들을 chat room의 다른 사용자들에게 되돌려준다. 따라서 10개의 chat room과 100개의 메시지의 경우 서버의 "보내기" 쓰레드는 10x20x100x19 또는 380,000 메시지를 보낼것이다. 클라이언트의 "받기" 쓰레드는 이에 상응하는 메시지를 받는다.
이 테스트는 명령행 세션에서 chat 서버를 시작하고 다른 명령행 세션에서 chat 클라이언트를 시작하는것으로 시작한다. 클라이언트는 워크로드를 시뮬레이션하고 결과는 클라이언트가 보낸 메시지의 수를 나타낸다. 클라이언트가 이 테스트를 끝내면 서버는 다른 시작 메시지를 클라이언트에서부터 루핑하여 받아들인다. 이 측정에서 우리는 20, 30, 40, 50 chat품으로 벤치마크를 실행했다. 상응하는 연결 및 쓰레드 숫자는 표 3에 나타나있다.
표 3. chat room과 메시지 수
| chat room의 수 | 연결 수 | 쓰레드 수 | 전송된 메시지 수 | 수신된 메시지 수 | 전체 메시지 수 |
| 20 | 400 | 1,600 | 40,000 | 760,000 | 800,000 |
| 30 | 600 | 2,400 | 60,000 | 1,140,000 | 1,200,000 |
| 40 | 800 | 3,200 | 80,000 | 1,520,000 | 1,600,000 |
| 50 | 1000 | 4,000 | 100,000 | 1,900,000 | 2,000,000 |
표 4는 chat 워크로드에 대한 Hyper-Threading의 퍼포먼스 효과를 보여준다. 각각의 데이터 포인트는 다섯개의 실행에 대한 도형이다. 이 데이터는 Hyper-Threading이 chat룸의 수에 따라 22%에서 28% 까지 워크로드 쓰루풋을 향상시킬 수 있음을 보여준다. 결국 Hyper-Threading은 chat 퍼포먼스를 24%까지 올렸다.
표 4. chat 쓰루풋에 대한 Hyper-Threading 효과
| chat room의 수 | 2419s-noht | 2419s-ht | Speed-up |
| 20 | 164,071 | 202,809 | 24% |
| 30 | 151,530 | 184,803 | 22% |
| 40 | 140,301 | 171,187 | 22% |
| 50 | 123,842 | 158,543 | 28% |
| Geometric Mean | 144,167 | 178,589 | 24% |
| 주: 데이터는 클라이언트에서 전송된 메시지의 수 이다. 큰 수일 수록 좋다. | |||
그림 1. chat 워크로드에 대한 Hyper-Threading 효과
리눅스 멀티쓰레드 파일 서버 워크로드에 대한 Hyper-Threading 효과
파일 서버에 대한 Hyper-Threading의 효과는 dbench와 동반 테스트인 tbench로 측정되었다.
dbench는 잘 알려진 NetBench 벤치마크와 비슷하다. 클라이언트에서 네트워크 파일 요청을 핸들할
때 파일 서버의 퍼포먼스를 측정한다. 하지만 NetBench가 실제 물리적 클라이언트에 대한 정교한 설정을
요구하는 대신, dbench는 90,000 작동을 시뮬레이팅한다. 이 파일의 내용은 SMBopenx, SMBclose,
SMBwritebraw, SMBgetatr 같은 파일 작동 디렉티브이다. I/O 호출은 SAMBA의 SMBD
서버가 NetBench 실행에서 만들어내는 Server Message Protocol Block (SMB)에
해당한다. SMB 프로토콜은 Microsoft Windows 3.11, NT, 95/98에 사용되어 디스크와
프린터를 공유한다.
이 테스트에서 총 18개의 다양한 유형의 I/O 호출이 사용되었다. (open file, read, write, lock, unlock, get file attribute, set file attribute, close, get disk free space, get file time, set file time, find open, find next, find close, rename file, delete file, create new file, flush file buffer).
dbench는 물리적 설정 없이도 모든 클라이언트를 시뮬레이팅한다. dbench는 단지 파일시스템 로드를 만들어내고 네트워킹 호출을 수행하지 않는다. 실행하는 동안 각각의 클라이언트는 이동하는 데이터의 바이트 수를 기록하고 데이터 이동에 걸리는 시간에 따라 수를 나눈다. 모든 클라이언트 쓰루풋 스코어는 서버를 위한 전체 쓰루풋을 결정하기위해 추가된다. 전체 I/O 쓰루풋 스코어는 테스트 동안 전송된 초당 메가바이트의 수를 나타낸다. 이것은 서버가 클라이언트에서 오는 파일 요청을 얼마나 잘 핸들하는지에 대한 측정이다.
dbench는 Hyper-Threading에 있어 훌륭한 테스트가 된다. 왜냐하면 이것은 CPU와 I/O 스케쥴러에 있어 높은 로드와 액티비티를 만들어내기 때문이다. 멀티쓰레드 파일 제공을 지원하는 하이퍼 쓰레드 기능은 dbench에서 진지하게 테스트된다. 왜냐하면 많은 파일들은 클라이언트에 의해 생성과 동시에 액세스 되기 때문이다. 각각의 클라이언트는 약 21메가바이트 정도의 테스트 데이터 파일을 만들어야한다. 20개의 클라이언트 실행을 테스트하기 위해서 약 420 메가바이트의 데이터가 실행된다. dbench는 리눅스 파일시스템에서 사용되는 정교한 알고리즘의 퍼포먼스를 측정하는데 좋은 테스트이다. dbench는 알고리즘의 작동 정확성을 테스트하는데 사용된다.
표 5는 dbench 워크로드에 대한 Hyper-Threading 효과를 나타낸다. 각각의 데이터 포인트는 다섯 개의 실행을 도형으로 표시했다. 이 데이터는 Hyper-Threading이 9%에서 29% 까지 dbench를 향상시켰음을 나타내고 있다. 전체적으로는 18%정도 나아졌다.
표 5. dbench 쓰루풋에 대한 Hyper-Threading 효과
| 클라이언트 수 | 2419s-noht | 2419s-ht | Speed-up |
| 20 | 132.82 | 171.23 | 29% |
| 30 | 131.43 | 169.55 | 29% |
| 60 | 119.95 | 133.77 | 12% |
| 90 | 111.89 | 121.81 | 9% |
| 120 | 99.31 | 114.92 | 16% |
| Geometric Mean | 118.4 | 140.3 | 18% |
| Note: Data are throughput in MB/sec: higher is better. | |||
그림 2. dbench 워크로드에 대한 Hyper-Threading 효과
tbench는 dbench와 비슷한 또 다른 파일 서버 워크로드이다. tbench는 오직 TCP와 프로세스 로드만 만들어낸다. tbench는 netbench 로드에서 SMBD 가 수행하는 것과 같은 소켓 호출을 수행하지만 tbench는 파일시스템 호출이 없다. tbench의 개념은 SMBD 코드가 빨라지더라도 netbench 테스트에서 SMBD를 줄이는 것이다. tbench의 쓰루풋 결과는 모든 파일시스템 I/O와 SMB 패킷 프로세싱을 줄인다면 netbench가 얼마나 빨리 실행될 것인지를 보여준다. tbench는 dbench 패키지의 일부로 구현된다.
표 6은 tbench 워크로드에 대한 Hyper-Threading 효과를 설명한다.
표 6. tbench 쓰루풋에 대한 Hyper-Threading 효과
| 클라이언트 수 | 2419s-noht | 2419s-ht | Speed-up |
| 20 | 60.98 | 79.86 | 31% |
| 30 | 59.94 | 77.82 | 30% |
| 60 | 55.85 | 70.19 | 26% |
| 90 | 48.45 | 58.88 | 22% |
| 120 | 37.85 | 47.92 | 27% |
| Geometric Mean | 51.84 | 65.77 | 27% |
| 주: 데이터는 MB/sec 이다: 높을 수록 좋다. | |||
그림 3. tbench 워크로드에 대한 Hyper-Threading 효과
Linux kernel 2.5.x의 Hyper-Threading 지원
Linux kernel 2.4.x는 2.4.17 부터 Hyper-Threading을 지원한다. 2.4.17 커널은 논리적 프로세서를 인식하고 있고 Hyper-Thread프로세서를 두 개의 물리적 프로세서로 취급한다. 하지만 2.4.x에 사용된 스케쥴러는 두 개의 논리적 프로세서와 두 개의 개별적인 물리적 프로세서 사이의 리소스 연결 문제를 구별하지 못하기 때문에 성숙한 것으로 보기 어렵다.
Ingo Molnar는 현재 시나리오가 잘못되어 가고 있다고 지적했다 (참고자료). 해결방법은 큐 작업을 실행하는 방법을 변경하는 것이다. 2.5 스케쥴러는 프로세서당 하나의 실행 큐를 갖고있고 큐 사이에 태스크를 이동하지 않는다. 이러한 변경은 태스크를 모든 가상 프로세서에 공급할 수 있는 물리적 프로세서당 하나의 실행 큐를 갖는 것이다.
2.5 스케쥴러에 실행 큐 변경과 더불어 리눅스 커널에는 Hyper-Threading을 사용할 수 있도록 하는 변경이 필요하다.
- HT 지원 수동적 로드 밸런싱:
IRQ 중심의 밸런싱은 물리적 CPU와 그 반대의 것이 되어야 한다. 그렇지 않으면 다른 물리적 CPU가 어떤 태스크도 수행하지 않고 하나의 물리적 CPU가 두 개의 태스크를 수행하게 된다.
- "적극적인" 로드 밸런싱:
논리적 CPU가 유휴가 되고 물리적 CPU가 불균형이 될 때이다. 이것은 1:1 스케쥴러에 존재하지 않는 메커니즘이다. 유휴 CPU에 의해 발생한 불균형은 일반적인 로드 밸런서를 통해 해결될 수 있다. Hyper-Threading의 경우 이러한 상황은 특별하다. 물리적 CPU 소스는 두개의 태스크를 실행하고 있기 때문이다. 로드 밸런서가 핸들할 수 없는 상황이다. 왜냐하면 실행 태스크는 마이그레이션이 어렵기 때문이다. 마이그레이션은 필수적이다. 그렇지 않으면 다른 물리적 CPU가 유휴로 남아있는 채 하나의 물리적 CPU가 두 개의 태스크를 실행한다.
- HT-지원 태스크 픽업:
스케쥴러가 새로운 태스크를 픽업하면 다른 CPU에서 태스크들을 가져오기 전에 같은 물리적 CPU를 공유하는 모든 태스크들을 선호한다. 스케쥴러는 특정 논리적 CPU에 스케쥴링된 태스크만 픽업한다.
- HT-지원 유연성:
태스크는 논리적 CPU가 아닌 물리적 CPU에 고정되어야 한다.
- HT-지원 실행(wake-up):
현재 스케쥴러는 "현재" CPU에 대해서만 알고있다. Hyper-Threading에서, 쓰레드가 이미 태스크를 실행하고 있는 논리적 CPU상에서 깨어있고 형제 CPU가 유휴상태면 형제 CPU는 깨어나서 새롭게 깨어난 태스크를 즉시 실행해야한다.
Linux kernel 2.5.32의 변화는 두 개 이상의 CPU를 갖춘 Xeon 시스템에 영향을 주도록 설계되었다.
표 7. Linux kernel 2.5.32 에서의 Hyper-Threading 효과
| chat workload | |||
| chat room의 수 | 2532s-noht | 2532s-ht | Speed-up |
| 20 | 137,792 | 207,788 | 51% |
| 30 | 138,832 | 195,765 | 41% |
| 40 | 144,454 | 231,509 | 47% |
| 50 | 137,745 | 191,834 | 39% |
| Geometric Mean | 139,678 | 202,034 | 45% |
| dbench workload | |||
| 클라이언트 수 | 2532s-noht | 2532s-ht | Speed-up |
| 20 | 142.02 | 180.87 | 27% |
| 30 | 129.63 | 141.19 | 9% |
| 60 | 84.76 | 86.02 | 1% |
| 90 | 67.89 | 70.37 | 4% |
| 120 | 57.44 | 70.59 | 23% |
| Geometric Mean | 90.54 | 101.76 | 12% |
| tbench workload | |||
| 클라이언트 수 | 2532s-noht | 2532s-ht | Speed-up |
| 20 | 60.28 | 82.23 | 36% |
| 30 | 60.12 | 81.72 | 36% |
| 60 | 59.73 | 81.2 | 36% |
| 90 | 59.71 | 80.79 | 35% |
| 120 | 59.73 | 79.45 | 33% |
| Geometric Mean | 59.91 | 81.07 | 35% |
| 데이터는 client/sec으로 전송된 메시지 수이다; dbench와 tbench 데이터는 MB/sec 이다. | |||
Intel Xeon Hyper-Threading은 리눅스 커널과 멀티쓰레드 애플리케이션에 긍정적인 영향을 미친다. Hyper-Threading의 속도향상은 2.4.19의 경우 30%, 2.5.32의 경우 51% 까지 높아졌다. 이것은 스케쥴러 실행 큐 지원과 Hyper-Threading 지원에 대한 과감한 변경 덕택이다.
- developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
- Linux
Benchmark Suite Homepage.
- dbench.
- LMbench
home page.
- NetBench
- Linux
elevator algorithm.
- Hyper-Threading
Technology Architecture and Microarchitecture.
- scheduler
and Hyper-Threading.
- Hyper-Threading
technology on the Intel Xeon processor family for servers.
- Linux
Technology Center.
목차
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그