동시 멀티스레딩

동시 멀티스레딩은 단일 물리적 프로세서가 둘 이상의 하드웨어 스레드 컨텍스트에서 동시에 명령을 내릴 수 있는 기능입니다. 물리적 프로세서당 2개의 하드웨어 스레드가 있으므로 추가 지시사항을 동시에 실행할 수 있습니다.

동시 멀티스레딩을 사용하면 동일한 프로세서에서 두 개의 애플리케이션을 동시에 예약하여 프로세서의 슈퍼스칼라 특성을 활용할 수 있습니다. 단일 애플리케이션은 프로세서를 완전히 포화시킬 수 없습니다.

동시 멀티스레딩의 이점

개별 트랜잭션의 속도가 수행되는 총 트랜잭션 수만큼 중요하지 않은 상업 환경에서 주로 유용합니다. 동시 멀티스레딩은 데이터베이스 서버나 웹 서버와 같이 작업 세트가 크거나 자주 변경되는 워크로드의 처리량을 증가시킬 것으로 예상됩니다.

동시 멀티스레딩의 이점이 가장 큰 워크로드는 CPI(명령어당 주기 수)가 높은 워크로드입니다. 이러한 워크로드는 프로세서 및 메모리 자원을 비효율적으로 사용하는 경향이 있습니다. 대형 CPI는 보통 대형 작업 세트에서 높은 캐시 미스 비율에 의해 발생합니다. 대형 상업 워크로드는 2개의 하드웨어 스레드가 지시사항 또는 데이터를 공유하거나 하드웨어 스레드가 완전히 별개의 것인지 여부에 따라 다소 다릅니다. 대형 상업 워크로드는 일반적으로 이 특성을 갖습니다. 운영 체제 또는 단일 애플리케이션 내에서 광범위하게 실행되는 것을 포함하여 명령어 또는 데이터를 공유하는 워크로드는 동시 멀티스레딩을 통해 더 많은 이점을 얻을 수 있습니다.

동시 멀티스레딩의 이점이 크지 않은 워크로드는 대부분의 개별 소프트웨어 스레드가 프로세서 또는 메모리의 모든 리소스를 대량으로 사용하는 워크로드입니다. 예를 들어 부동 소수점 집약적인 워크로드는 동시 멀티스레딩을 통해 얻을 수 있는 이득이 거의 없으며 성능 저하가 발생할 가능성이 가장 높습니다. 이러한 워크로드는 부동 소수점 단위 또는 메모리 대역폭을 많이 사용합니다. CPI가 낮고 캐시 미스 비율이 낮은 워크로드는 일부 작은 혜택을 볼 수 있습니다.

상업 워크로드가 있는 전용 파티션에서 수행된 측정에서 처리량이 25%-40% 증가했음을 표시했습니다. 동시 멀티스레딩은 공유 프로세서 파티션 처리에 도움이 됩니다. 추가 스레드는 파티션이 작업 세트를 더 빨리 복구하기 때문에 동시 멀티 스레딩이 파견된 후 파티션의 성능을 향상시킵니다. 후속적으로, 스레드는 전용 파티션에서와 같이 수행합니다. 다소 직관적이지 않을 수 있지만, 동시 멀티스레딩은 캐시 성능이 최악일 때 가장 좋은 성능을 발휘합니다.

smtctl 명령으로 모드 설정

AIX® ' smtctl ' 명령으로 동시 멀티스레딩을 위한 파티션의 모드를 제어할 수 있습니다. 이 명령을 사용하면 즉시 또는 다음에 시스템을 부팅할 때 시스템 전체에서 동시 멀티스레딩을 켜거나 끌 수 있습니다. 동시 멀티스레딩 모드는 시스템 부팅 시에도 지속됩니다. 기본적으로 AIX 동시 멀티스레딩을 활성화합니다.

smtctl [ -m { off  | on } [ { -boot | -now } ] ]

동시 멀티스레딩을 위한Hardware Management Console 구성

HMC(Hardware Management Console)에서 공유 프로세서 파티션을 구성할 때 가상 프로세서의 최소 수, 원하는 수 및 최대 수를 지정합니다. 전용 파티션의 경우 동일한 매개변수 유형을 지정하지만 프로세서 용어는 다릅니다. 전용 파티션의 경우 프로세서는 항상 프로세서라고 합니다.

두 분할 모델 모두 프로세서의 부트 및 실행시간 지정을 제어하는 프로세서의 범위를 파티션에 지정해야 합니다. 가능한 경우, 원하는 프로세서 설정이 시스템 시작 시 승인됩니다. 이것이 가능하지 않은 경우 POWER Hypervisor 사용 가능한 리소스 집합에 따라 최소값보다 크거나 같은 다른 값을 선택합니다.

HMC에 지정된 프로세서 갯수는 AIX에서 할당하는 논리적 프로세서 갯수에 영향을 줍니다. 파티션이 동시 멀티스레딩이 가능한 경우 프로세서당 2개의 하드웨어 스레드가 있고 AIX 각 하드웨어 스레드를 별도의 논리 프로세서로 구성하므로 AIX 최대 프로세서 값의 두 배에 해당하는 논리 프로세서를 할당합니다. 이를 통해 AIX 파티션을 재부팅하지 않고도 동시 멀티스레딩을 활성화 또는 비활성화할 수 있습니다.

동시 멀티스레딩을 위한동적 논리 파티셔닝

파티션이 실행되는 동안에는 HMC에서 동적 논리 파티셔닝(DLPAR) 절차를 통해 파티션에 할당되는 프로세서 수를 변경할 수 있습니다. 파티션에 정의된 프로세서 범위의 제한조건 내에서 프로세서를 추가하거나 제거할 수 있습니다. 동시 멀티스레딩이 활성화된 파티션에 프로세서가 추가되면 AIX 하드웨어 스레드를 모두 시작하고 두 개의 논리적 프로세서가 온라인 상태가 됩니다. 동시 멀티스레딩이 활성화된 파티션에서 프로세서가 제거되면 AIX 하드웨어 스레드를 모두 중지하고 두 개의 논리적 프로세서가 오프라인 상태가 됩니다.

동시 멀티스레딩이 활성화되면 두 개의 DLPAR 이벤트가 생성됩니다. 추가되거나 제거되는 각 논리적 프로세서마다 하나의 이벤트가 생성됩니다. DLPAR 스크립트의 API는 논리적 프로세서에 기반하므로, DLPAR 이벤트의 수가 논리적 프로세서의 추가 및 제거에 평행합니다. 파티션에서 동시 멀티스레딩이 활성화되어 있지 않은 경우 DLPAR 이벤트는 하나만 발생합니다. AIX에서는 HMC에서 전송되는 DLPAR 요청을 DLPAR 인식형 응용프로그램에 나타나는 해당 DLPAR 이벤트 갯수로 자동 변환합니다.

마이크로 파티셔닝® 및 동시 멀티스레딩

POWER Hypervisor™ 가상 프로세서를 선점하거나 디스패치할 때 필요한 모든 프로세서 상태를 저장하고 복원합니다. 동시 멀티스레딩이 활성화된 프로세서의 경우 이는 두 개의 활성 스레드 컨텍스트를 의미합니다. AIX에서 각 하드웨어 드레드를 별도의 논리적 프로세서로 지원합니다. 따라서 하나의 물리적 프로세서로 작성된 전용 파티션은 AIX에서 논리적 양방향 프로세서로 구성설정됩니다. 이 구성설정은 파티션 유형과는 무관하므로 두 개의 가상 프로세서와 공유되는 파티션은 AIX에서 논리적 4방향 프로세서로, 4개의 가상 프로세서와 공유되는 파티션은 AIX에서 논리적 8방향 프로세서로 구성설정됩니다. 쌍으로 지정된 스레드는 항상 동일한 파티션에서 동시에 함께 스케줄링됩니다.

공유 프로세서 용량은 항상 전체 물리적 프로세서를 통해 전달됩니다. 동시 멀티스레딩을 사용하지 않는 경우, AIX 200개의 프로세서 권한을 가진 4방향 가상 프로세서 파티션을 각 논리 프로세서가 물리적 프로세서의 50%의 성능을 갖는 4방향 논리 프로세서 파티션으로 구성합니다. 동시 멀티스레딩을 사용하면 4방향 논리 프로세서 파티션이 8방향 논리 프로세서 파티션이 되며, 각 논리 프로세서의 성능은 물리적 프로세서의 약 25%에 해당합니다. 그러나 동시 멀티스레딩을 사용하면 일반적으로 가상 프로세서의 부분 용량과 관련된 지연 시간 문제가 스레드에 선형적으로 적용되지 않습니다. 두 스레드 모두 함께 작업 지정되므로, 50% 작업 지정 윈도우의 기간 동안 활성이고 논리적 25%를 달성하는 데 기존 물리적 프로세서를 공유합니다. 즉, 각 논리적 프로세서에서는 해당 개별 용량에서 허용하는 시간의 2배가 되는 시간 동안 인터럽트를 처리할 수 있습니다.

하드웨어 스레드 우선순위

프로세서를 통해 우선순위가 하드웨어 스레드에 지정될 수 있습니다. 시블링 스레드 간의 우선순위 차이를 통해 각 스레드에 할당된 물리적 프로세서 암호 해독 슬롯 비율을 판별합니다. 슬롯의 수가 많으면 스레드 성능이 향상됩니다. 보통 AIX에서는 시블링 스레드를 동일한 우선순위로 유지하지만 중요한 위치에서 스레드 우선순위를 올리거나 낮춰 성능을 최적화합니다. 예를 들어, 스레드가 유휴 루프 또는 커널 잠금에서 회전하는 사용자 데이터 불포함 작업을 수행 중일 때 AIX에서는 스레드 우선순위를 낮춥니다. 스레드 우선순위은 스레드가 중요한 커널 잠금을 보유하는 경우 올라갑니다. 이러한 우선순위 조정은 사용자 모드에서 지속되지 않습니다. AIX에서는 하드웨어 스레드 우선순위를 선택할 때 소프트웨어 스레드 작업 지정 우선순위를 고려하지 않습니다.

작업은 2차 스레드에 작업 지정되기 전에 모든 1차 스레드 간에 분배됩니다. 스레드의 성능은 쌍으로 지정된 스레드가 유휴 상태일 때 가장 좋습니다. 또한 스레드 선호도를 유휴 스틸링 및 주기적인 실행 큐 로드 밸런싱에서 고려합니다.