Sun Developer Network 공식 블로그

리처드 맥두걸, 썬마이크로시스템즈 수석 엔지니어 및 "Solaris Internals" 저자

듀얼코어의 대중화가 빨라지고 있습니다. 듀얼코어 같은 CMP 시스템에서 개발자들이 알아야할 정보를 제공합니다.
Part 1 : SMP & 확장성 CMT와 SMP의 개념과 그 차이점에 대해서 설명하고 CMT의 확장성에 관해서 개발자들이 이해하기 쉽도록 간단한 법칙과 그래프를 제시합니다.
Part 2 : 개발영역에의 영향력 & 실험 CMT가 어플리케이션 개발자들에게 미칠 수 있는 영향과 그에 따른 확장성에 대한 고려사항을 설명하고 CMT가 기존 상용 소프트웨어들에게 미칠 수 있는 라이센스 문제에 관해 설명합니다.
Part 3 : OS 영역에의 영향력 & 병렬처리 OS의 확장성에 대해 FreeBSD, Solaris, Linux 등 각 OS를 통해 설명하고 병렬처리에 대한 새로운 개념을 제시합니다.

이번달에는 Part 3: OS 영역에서의 영향력 & 병렬처리에 대해 다룹니다.
Part 1 : SMP & 확장성 보기?
Part 2 : 개발영역에의 영향력 & 실험 보기?

5. OS영역에서의 영향력

CMP가 OS에 미치는 영향력

OS에 있어서 두가지 도전과제가 있습니다. 어플리케이션에 확장가능한 시스템 서비스를 제공하는 것과 병렬처리 프로그램을 쉽게 개발할수 있도록 하기 위해 확장가능한 프로그래밍 환경을 제공하는 것입니다.

OS를 위한 CMP 개선점

SMP가 가능한 OS커널은 CMP하드웨어상에서도 꽤 잘 작동합니다. 하나의 칩안에 있는 각각의 코어나 하드웨어 스레드들은 전체 레지스터를 가지고 있기때문에, 소프트웨어에게 각각 별도의 CPU처럼 보입니다. SMP가 가능하지 않은 OS에서는 하나의 칩안에 있는 모든 하드웨어 스레드에게 간단히 하나의 논리 프로세서처럼 보여지게 될 것입니다. 소프트웨어 스레드는 각각의 하드웨어 스레드가 SMP시스템안에 처음 들어온 순간의 OS시스템 커널의 스케쥴 정책에 따라 동일한 비중을 가지고 스케쥴링 될 것입니다.(그림 5 참조)

CMT 프로세서를 최적화 하기 위한 기본적인 변화는 모든 바쁜(busy) 대기 루프를 제거하는 입니다. 예를 들어 전형적인 대기 상태의(idle) 루프는 다른 작업을 하기 위해 런 큐를 체크하는 루프로 구현되어져 있습니다. 여러개의 하드웨어 스레드가 하나의 코어를 공유할때, 하나의 스레드 상에서 운영되는 대기중인 루프는 코어의 파이프라인을 공유하는 다른 스레드들에게 악영향을 미칠 것입니다. 이 예에서는 처리할 일이 없을때에는 하드웨어의 기능과 협력하여 스레드를 대기시기는 것이 더욱 효과적입니다.

이후의 OS의 기능 향상은 CMP들의 교묘한 차이를 최적화 하는데 목적을 두게 될 것입니다. 예를 들어 스케줄러는 프로세서 구조에 대한 지식과 소프트웨어의 행동에 대한 약간의 정보를 가지고 특정한 하드웨어 스레드상에 소프트웨어 스레드를 최적화시켜 배치 할 수 있을것입니다. 여러개의 하드웨어 스레드가 하나의 코어, 첫번째-레벨 캐시(L1), TLB(translation look-aside buffer)를 공유하는 CMP구조의 경우, 비슷한 메모리 접근 패턴(건설적인)을 가지는 소프트웨어 스레드가 동일한 코어상에 함께 위치해 있는지 여부와 파괴적인 패턴을 가지는 소프트웨어 스레드가 다른 코어상에 분리되었는지 여부에 따라 이득이 있을 수 있습니다.

OS 확장

역사적으로 OS 서비스들의 확장은 서비스 인스턴스들과의 공유 상태에 대한 문제로 인식되어져 왔습니다. 예를 들어 새로운 프로세스를 실행하기 위한 프로그램에 의해 접근되고 수정되어지는 글로벌 프로세스 테이블에 대해 생각해 봅시다. 멀티프로세서 시스템에서 동기화 기술은 두개 혹은 더 많은 수의 쓰레드가 동시에 프로세스 테이블에 대한 수정을 시도할때에 발생하는 레이스 컨디션 상태를 해결하기 위해 반드시 사용되어져야 합니다.

일반적인 기술들은 이러한 구조에 접근하는 코드나 데이타 구조 그 자체의 코드 둘중의 하나 에서 시리얼화를 요구합니다. 유닉스를 SMP하드웨어로 포팅하려는 초기의 시도들은 조잡했습니다 - 그들은 주로 존재하는 단순하고 정밀하지 못한 시리얼화를 가진 OS코드를 재구성 했습니다. 예를들어 첫번째 SMP유닉스 시스템은 OS커널이 모든 요청을 자신의 데이타 구조에 시리얼화 하기위해서 OS커널을 중심으로 한 하나의 글로벌락으로 구현한 것을 약간 수정하였습니다. 초기의 SunOS(1.x), Linux(2.2), FreeBSD(4.x) 커널은 이러한 접근방법을 이용했습니다. 이러한 접근방법은 구현하기는 쉬웠지만, 단지 OS서비스를 거의 쓰지 않는 어플리케이션에 대한 확장성에만 도움을 주었을 뿐이었습니다. 전체적으로 계산을 위주로 하는 어플리케이션들은 좋은 확장성을 보여주었지만, 많은 양의 OS서비스를 사용하였기 때문에 하나의 프로세서를 넘어서는 범위에서는 확장성이 거의 없거나 완전 없는 시리얼화를 경험하였습니다.

반대로 성공적인 OS확장은 단지 잘 다듬어진 데이타 구조가 시리얼화 하는것을 막아 경쟁을 최소화하는것으로 얻을 수 있었습니다. 이러한 방법으로 여러개의 프로세서상의 동일한 영역에 동시에 존재하는 코드를 공유되어있는 데이타 구조에 접근할때만 일시적으로 시리얼화 함으로써 실행할 수 있었습니다. 하지만 이러한 접근방법은 OS에 상당히 구조적인 변화를 요구하였고 어떤 경우에는 확장성에 맞추어 근본부터 다시 만들어야했습니다.

잘 만들어진 OS는 OS서비스를 통하여 높은 수준의 동시처리를 가능하게 합니다. 특히 어플리케이션은 라이브러리, 메모리할당, 다른 시스템 서비스를 통하여 시스템 서비스를 불러일으키며,그 어플리케이션들은 공유자원에 접근할때에도 반드시 병렬로 처리를 하게 되어 있습니다. 확장성에 있어 다른 중요한 부분은 I/O같은 공유된 하드웨어와 네트워크로 연결된 서브시스템과 같은 병렬 접속을 포함합니다.

FreeBSD에서의 확장 강화

FreeBSD는 커널 5.x때부터 확장에 큰 노력을 보여왔습니다. 구조적인 변화는 새로운 커널 메모리 할당자, 루틴 동기화, ithreads의 이동을 포함하며, 프로세서 스케쥴링, 가상 메모리, 가상 파일시스템, UFS(Unix file system:유닉스 파일시스템), 네트워킹 스택, 프로세스간의 내부 커뮤니케이션 같은 활동으로부터 글로벌 커널 락을 제거하는 것도 포함하고 있습니다. FreeBSD는 성공적으로 확장성을 높여왔습니다. (12개의 프로세서까지 사용가능하다고 여겨짐)

Linux에서의 확장 강화

글로벌 커널 락을 분리시킨 Linux2.2 커널에서 확장성은 매우 크게 향상되어, 2~4개의 프로세서까지 확장시킬수 있었습니다. Linux2.4의 확장성은 스케쥴러와 I/O서브시스템에서의 락킹을 더욱 정밀하게 함으로써 8~16개로 향상되었습니다. 이는 인터럽트나 I/O 같은 많은 아이템들에 대하여 확장성을 향상시켰습니다. 이후에 Linux커널에대한 노력은 많은 수의 프로세서에 대한 확장성으로 초점을 옮겨갔고 네트워크로 연결된 서브시스템을 통해 동시처리를 향상시켰습니다.

Solaris에서의 확장 강화

솔라리스 OS는 동시처리에 대한 개념을 바탕으로 설계되었으며 시리얼화를 자료구조의 아주 중요한 부분에만 극소로 사용합니다. 솔라리스는 실행 문맥들이 병렬적으로 수행되고 스케줄되는 독립적인 소프트웨어 쓰레드들로 이루어 졌다는 개념을 바탕으로 디자인 되었습니다.

기존 유닉스의 메모리 할당자들을 Slab과 Vmem 할당자로 교체함으로써 확장성에 큰 이득을 가져왔습니다. 이 할당자들은 오브젝트 셋 사이즈가 증가해도 안정적으로 제시간에 할당을 해주며 각 프로세서에 대해 글로벌 스트럭쳐의 접근 없이도 메모리를 할당하고 회수 할 수 있는 메모리 풀을 제공함으로써 락킹을 사용하지 않는데 집중하고 있습니다.

확장가능한 I/O는 같은 디바이스 드라이버 안에서도 동시에 실행가능하도록 요청 스레드를 허용하게 만들었고, 더 나아가서 인터럽트 핸들링의 확장을 가능하게 하는 분리된 스레드의 형태로, 하드웨어 장치에서 발생하는 인터럽트를 처리할 수 있게 하였습니다.

몇몇 경우에서, 데이타 구조에 동시에 접근할 수 있도록 하는 높은레벨의 접근을 요구합니다. 예를 들어 IO 디바이스의 성능 통계를 위해서는 잠재적으로 수천개의 동시작업이 요구됩니다. 이러한 구조에서 작업들간의 충돌을 완화시키기 위해서는 통계가 프로세서 기반으로 하여 요청시에만 수집이 되도록 하여야 합니다. 이러한 방법은 오직 통계를 읽어 올때에만 시리얼화가 발생하도록 해줍니다.

Solaris 네트워킹 코드는 커넥션마다의 상하경계(vertical perimeter)를 도입함으로써 글로벌 데이타 구조의 대부분을 제거하기위해 재구성되었습니다. 이것은 하나의 커넥션 안에서 오로지 라우팅과 같은 글로벌 이벤트가 변화할때만 락킹을 요청하여 거의 락이없는 모드로 동작할수 있도록 TCP/IP 구현을 가능하게 하였습니다.

통합된 관찰도구는 확장을 최적화하는 이슈의 열쇠입니다. 실시간으로 워크로드를 가지는 시스템상의 락킹 경쟁의 관찰을 위한 근본적인 설비는 중요한 부분의 성능향상을 위해 매우 중요합니다. 더욱 최근에, 퍼포먼스의 최적화에 대한 또 하나의 혁신적인 접근법이라 여겨지는 Dtrace는 C와 Java코드가 동적으로 작업을 수행할 수 있도록 하였습니다. Dtrace는 OS 전반에 걸쳐 어플리케이션 스택으로부터 경쟁의 원인을 정확히 잡아낼 수 있게 하였습니다.

이러한 타입의 기술은 Solaris 커널이 수천개의 스레드로 확장 가능하게 하였고, 1백만 I/O를 매초 실행할수 있게 하였고, 물리적인 프로세서들을 수백개까지 확장할 수 있게 하였습니다. 수월하게도, 이러한 확장에 관한 작업은 CMP 시스템의 지렛대 역할을 하였습니다. 여기에 묘사된 것처럼 큰 SMP확장에 매우 중요한 기술들은 심지어는 CMP 시스템의 가장 낮은 엔트리 레벨에까지 요구되고있습니다. 다음 5년 안에, CMP하드웨어 확장이 시스템당 512개 프로세서 스레드로 확장되고, 그에 준하는 OS확장을 요구할것을 기대하여도 좋습니다.

OS 사용효율 측정법

멀티스레드 코어로 된 시스템상에서 프로세서 사용효율에 대한 보고는 어려운 문제입니다. 싱글-코어 칩에서, 산출량은 종종 프로세서 사용효율과 정비례하게 증가합니다. 멀티스레드 칩에서는 하드웨어 스레드간의 리소스 공유라는 더욱 큰 특징이 있고, 그렇기 때문에 산출량과 실제의 프로세서 사용 효율은 정비례하지는 않습니다. 결과로, 이미 보고된 프로세서 사용효율에 따른 ‘헤드룸’(headroom: 여유분)의 계산은 더 이상 정확하지 않습니다.

예를 들어, Intel Xeon과 같이 2개의 스레드를 가지는 프로세서 코어(하이퍼스레딩)는 OS에 2개의 나뉘어진 프로세서로 보여집니다. 만약 소프트웨어 스레드(가상 프로세서)가 한쪽 부분만을 계속 쓰고, 다른 부분의 스레드들은 완전히 아무 것도 하지 않는다고 한다면, 프로세서는 OS에 의해 50%로 일하고 있다고 나타날 것입니다. Xeon 구조상(하드웨어 관점)에서는, 이 두 부분의 스레드들은 단지 10%정도의 산출량 증가를 보이면서도, 두 스레드가 모두 사용 중이기 때문에 100% 사용하고 있다고 보고될 것입니다. 그러므로 이러한 시스템은 이것이 최대 산출량의 90%를 내고 있을 때 50%의 사용효율을 보이고 있다고 보고할 것입니다.

이러한 효과는 자원이 얼마나 많은 자원이 프로세서 안의 하드웨어 스레드에 의해 공유되었는가에의해 좌우될 것입니다. 그리고 궁극적으로 이 효과는 시스템의 사용효율 측정에 대한 의미를 약간의 새로운 기능을 더하여 재정의해야한다는 요구를 낳게 될 것입니다.

6. 병렬처리

병렬처리를 위한 가상화 촉진

지금까지 우리는 각각의 어플리케이션이나 OS의 확장을 통한 CMT들로 많은 하드웨어 스레드들을 쓰기 위한 방법을 찾기위해 조사해봤습니다. 이러한 리소스를 효과적으로 쓰는 또 다른 방법은 여러개의 확장불가능한 어플리케이션을 (core 혹은 virtual processor만큼) 쓰거나 심지어는 OS 기술이나 서버 가상화 기술을 이용하여 활용성을 높일 수 있는 OS를 사용하는 것입니다.

이러한 기능은 일반적으로 하나의 서버상으로 통합가능한 여러개의 어플리케이션 인스턴스를 가능하게 합니다.

예를들어, Solaris Container 기능은 여러개의 어플리케이션이 하나의 OS 인스턴스 안에 존재할 수 있도록 합니다. 이러한 환경으로 당신은 어플리케이션이 증가됨에 따라 누적되어 동시처리 될 수 있습니다. 각각 16개의 동시처리 스레드를 가지는 웹 서버를 2개 더함으로써, 당신은 시스템 범위의 동시처리를 32 스레드로 증가시킬 수 있습니다. 이러한 부가적인 작용은 제한된 확장성안에서 CMP시스템의 최대 동시처리를 이용할 수 있게 어플리케이션을 배치할수 있도록 해주는 유용한 메커니즘을 나타냅니다.

가상화 기술에 관련된 또다른 내용은, 가상화 머신 환경입니다. 가상화 머신 환경은 여러개의 OS인스턴스가 하나의 하드웨어 플랫폼 안에서 운영 가능하게 합니다. 가상화 머신 기술에 대한 예는 VMware와 Xen입니다. 이러한 환경들은 하나의 OS상에서 어플리케이션이나 OS들의 통합을 할수있게 하며, 조금의 수고로움을 필요로 하지만, 심지어 CMP구조상에서 확장 불가능한 OS를 배치시킬 수 있는 메커니즘을 제공하기도 합니다.

CMP는 개발자들의 재고를 요구한다

CMP시스템의 소개는 시스템을 확장하는데, 새로운 차원에서 엄청난 기회를 제공합니다. CMP시스템의 가장 큰 영향은 확장의 기본 단위가 크게 증가했다는 것입니다 : 로우엔드 하나 또는 두개의 프로세서를 쓰는 가장낮은 엔트리 레벨 시스템은 이제 16~32way 시스템까지로 보고 있으며, 곧 미드레인지 시스템 또한 수백개의 way로 확장될 것입니다.

어플리케이션 개발자들에게 있어서 CMP시스템의 소개는 여러 어플리케이션을 가지는 단일장비내의 확장성에 대한 새로운, 또는 수정된 관점을 보여주었으며, 소프트웨어 라이센스 비용을 어떻게 계산해야하는가에 대하여 다시 생각해보게 하였습니다. OS 개발자에게 수백개로 way를 확장 가능해야 한다는건 하나의 요구조건이 되었습니다. 개발자에게 CMP는 어플리케이션 확장하는 새로운 방법을 제시하였으며, 우리가 시스템안에서 설계하고, 튜닝할때 고려하도록 요구할 것이며, 용량을 효과적으로 쓰는 계획을 세우는 기술들도 요구할 것입니다.

참조

1. AMD Opteron Processor; http://www.amd.com.
2. Kongetira, P., Aingaran, K., and Olukotun, K. 2005. Niagara: a 32-way multithreaded SPARC processor. IEEE Micro 25 (2): 21?29.
3. Amdahl, G. M. 1967. Validity of the single-processor approach to achieving large-scale computing capabilities. Proceedings of AFIPS Conference: 483-485.
4. The FreeBSD SMP Project; http://www.freebsd.org/smp/.
5. Bonwick, J. 1994. The Slab allocator: an object-caching kernel memory allocator. Sun Microsystems.
6. Bonwick, J., and Adams, J. 2001. Magazines and Vmem: extending the Slab allocator to many CPUs and arbitrary resources. Sun Microsystems and California Institute of Technology.
7. Kleiman, S., and Eykholt, J. 1995. Interrupts as threads. ACM Sigops Operating Systems Review 29 (2): 21-26.
8. Tripathi, S. 2005. Solaris OS network performance. Sun White Paper (February).
9. Cantrill, B. M., Shapiro, M. W., Leventhal, A.H. 2004. Dynamic instrumentation of production systems. Usenix Proceedings.

저자에 관하여

Richard McDougall, 만약 그가 100년 전에 살았더라면 발전을 꾀하는 새로운 기술들을 탐구하며 4-행정 내연기관차의 서막을 열었을 것입니다. 그는 복잡한 문제를 푸는 간단한 방법 찾기를 추구하며, 새로운 기술을 경험하는 선구자들이 그 기술이 어떻게 작동하는지 이해할 수 있도록 최대한 돕고 있습니다. 그는 썬마이크로시스템즈의 뛰어난 엔지니어이며, OS기술과 시스템 퍼포먼스 전문가 입니다. 그는 Solaris Internals(솔라리스 인터널:Prentice Hall,2000;second edition,2005)과 Resource Management(리소스 관리: Prentice Hall, 1999)의 저자이기도 합니다.