컬럼/인터뷰
저자: Federico Biancuzzi, 한동훈 역
원문: http://www.onlamp.com/pub/a/bsd/2005/01/20/smpng.html
지난 5년 동안 FreeBSD 개발팀은 멀티 프로세서 시스템의 성능을 향상시키기 위해 많은 노력을 기울여 왔다. FreeBSD 개발팀의 목표는 4.x 대에서 사용되었던 Big Kernel Lock을 제거하고, 보다 정교한 SMP 지원을 제공하는 것이었다. 흔히 SMPng라 언급되는 SMP next generation 프로젝트는 많은 노력이 필요했으며, 안정화 상태에 도달하기 위해 5.0에서 5.3까지 4개의 릴리스를 거쳐와야했다.
역주: Big Kernel Lock: 리눅스의 SMP 지원 초기에 제공되었던 그다지 정교하지 못한 버전의 잠금(Lock) 메커니즘을 의미한다.
페데리코 비안쿠지(Federico Biancuzzi)는 SMPng 기술, 현재 구현 상태, 앞으로의 목표와 계획에 대해 FreeBSD의 코어 멤버인 스캇 롱(Scott Long)과 인터뷰하였다.
소개를 부탁드려도 될까요?
스캇: 저는 30세이며, 결혼한지 7년된 아내와 각각 4살과 6살인 아이들과 함께 콜로라도 주 보울더 근교에서 살고 있습니다. 현재 캐나다 워러투에 있는 Sandvine 회사에서 FreeBSD 시스템 지원을 하고 있습니다. 전에는 거의 5년 동안 Adaptec에서 오픈 소스 그룹의 일원이었습니다. FreeBSD 일을 하지 않을 때는 그리 멀지 않은 산에서 바이킹, 하이킹, 캠핑을 하는 것을 즐깁니다.
역주: 보울더는 콜로라도주 덴버시 북서쪽으로 1시간 정도 떨어진 곳에 위치한 지방
프로젝트에서 맡은 역할은 무엇인가요?
스캇: 저는 FreeBSD 태동기부터 사용해 왔으며, 2000년 이후로는 기여 회원(contributing member)로 있습니다. 현재는 일련의 5.x 릴리스의 릴리스 엔지니어링을 이끌어 가고 있으며, 최근에는 FreeBSD 코어 팀(Core Team)을 제안받았습니다.
제 주요 관심사는 스토리지에 대한 것입니다. 저는 FreeBSD RAID 드라이버의 대부분을 관리하고 있으며, UDF 파일 시스템 지원을 작성했습니다. 최근에는 보다 작고 견고한 USB 드라이버를 몇 개 작성했습니다.
다양한 잠금(Lock)의 차이점을 알지 못하는 독자들을 위해 그것들을 요약해 주시겠습니까?
스캇: 스핀락(spin lock)은 잠금을 할 수 없는 경우 CPU가 중단없이 코드를 빙글빙글 돌면서(역주: 이를 spin한다고 함) 잠금을 획득할 때 까지 반복하는 뮤텍스입니다. CPU는 잠금을 획득하기 전에는 어떤 일도 수행하지 않습니다.
역주: 리눅스에서는 버저락(Buzz Lock)이라고 알려져 있다. 대부분의 CPU에서는 하드웨어적으로 이를 지원하고 있으며, 지원하지 않는 시스템에서는 캐시되지 않는 메인 메모리를 사용하여 이를 구현하고 있다.
슬립 락은 잠금을 이용할 수 없는 경우 현재 스레드나 프로세스를 재웁니다(sleep). 잠금을 획득하고 있는 스레드나 프로세스가 잠금을 해제할 때 이 스레드가 깨어나게 됩니다. 반면에, CPU는 다른 스레드를 실행하기 때문에 Busy 상태가 될 것입니다.
SX 락(shared-exclusive lock)은 여러 스레드가 읽기 상태에 있는 것을 동시에 접근할 수 있게 하지만, 오직 하나의 스레드만 쓰기 상태를 획득할 수 있습니다. 읽기, 쓰기는 잠금에 의해 보호되는 리소스에 의해 수행되는 동작을 의미합니다.
역주: 주로 reader-writer lock 또는 provider-consumer lock으로 알려져 있다.
블로킹(blocking)은 슬리핑(sleeping)과 동의어 입니다. 스레드가 블록될 때, 스레드를 스케줄러의 슬립 큐(sleep queue)에 넣고, 잠금 해제와 같은 이벤트가 발생할 때 까지 슬립큐에 대기하게 됩니다.
세마포어 세기(Counting semaphores)도 사용할 수 있습니다. 이것은 잠금을 동시에 획득하기 위해 예정된 수 만큼의 스레드를 허용하는 형태의 슬립 락입니다.
FreeBSD 4 SMP는 어떻게 동작합니까?
스캇: SMP를 구현하는 전형적인 방법은 userland 프로세스를 동시에 실행하는 것이지만, 오직 한 CPU만 한 번에 커널 안에 있을 수 있습니다. 이것을 커널에 대한 진입을 제한하는 스핀 락, 즉 "mplock"에서 수행됩니다.
이러한 구현이 갖는 문제점은 무엇입니까?
스캇: 이러한 접근 방법은 주로 유저랜드에서 실행되거나 계산만 수행하는 작업부하에 대해서는 잘 동작하지만 과도한 I/O, 네트워크, 커널 서비스에 대한 작업 부하에 대해서는 매우 취약합니다.
FreeBSD 5 SMPng에서는 이 문제를 어떻게 해결했나요?
스캇: FreeBSD 5에서 mplock은 제거되었습니다. mplock 대신에 대양한 커널 서비스들이 동기화와 다중 프로세서 안정성을 허용하는 일련의 잠금과 동기성 기본요소(synchronization primitives)가 사용됩니다. 여러 프로세스가 동시에 커널에 머무를 수 있습니다.
두번째 큰 변화는 인터럽트 스레드라 불리는 특별한 커널 프로세스 컨텍스트에서 대부분의 작업을 수행합니다. 인터럽트 스레드를 사용하면 드라이버가 슬리핑동안에 전체 CPU를 블로킹하지 않고 인터럽트 핸들러의 슬립 락을 사용할 수 있습니다.
명확하게 MPSAFE로 되어있지 않은 부분, 즉 "Giant"라 불리는 글로벌 뮤텍스가 존재하며, 이것은 4.x대의 mplock과 비슷한 방식으로 보호를 수행합니다. 따라서, 현재 기본적인 목표는 기존 코드를 MPSAFE로 만드는 것과 최대한 Giant를 제거해 나가는 것입니다.
인터럽트 스레드는 무엇입니까?
스캇: 인터럽트 스레드는 커널안에 머무르는 일반 스레드입니다. 이 스레드의 유일한 목적은 드라이버 인터럽트 핸들러에 실행 컨텍스트를 제공하는 것입니다. 인트럽트 스레드를 사용하면 드라이버가 리소스에 대한 블록이나 잠금과 같은 전형적인 인터럽트 컨텍스트에서 허용되지 않던 작업들을 수행할 수 있습니다.
전형적인 인터럽트 컨텍스트는 ithread를 스케줄하기 위해 사용합니다. latency에 영향을 받으며, 블로킹을 사용하지 않는 일부 드라이버는 인터럽트 컨텍스트에서 직접 인터럽트 핸들러를 수행할 수 있으며, ithread를 사용하지 않을 수 있습니다. 그러나, 이것은 매우 특별한 경우에 해당합니다.
DragonFlyBSD의 SMP 기술에 대해 어떻게 생각하십니까? SMPng와 어떤 점이 다른가요?
스캇: DragonFly의 방법은 공유 데이터 구조에 대한 액세스를 동기화하는 방법 대신 서브 시스템간에 메시지를 주고 받는 방식으로 동시성을 구현하는 방법은 Mach나 AmigaOS에서 사용된 것과 매우 비슷해 보입니다. DragonFly의 작업은 아직 유아기에 머물러 있지만, 계속 주시할 것이며, 어떻게 발전해 가는지 지켜볼 것입니다.
NetBSD/OpenBSD SMP는 어떻습니까?
스캇: 저는 OpenBSD에 익숙하지 않지만, NetBSD는 FreeBSD 4.x와 같은 접근방법을 사용하고 있는 것으로 보입니다. 최근 벤치마크에 따르면 NetBSD 2.0이 FreeBSD 5.x보다 빠르다고 합니다. 여기서 실시한 테스트 결과에 따르면 FreeBSD가 대부분 보다 높은 수치에서 끝났습니다. 이것들은 FreeBSD 5.x의 SMPng 잠금의 비용을 보여주고 있습니다. 당장 이 문제를 해결하기에는 작업이 많은 편입니다.
FreeBSD SMPng는 리눅스 SMP보다 나은 성능을 보여줄 수 있을까요?
스캇: SMPng 설계 목표중에 하나는 스핀 락 대신에 슬립 락 사용을 활성화하는 것입니다. 슬립 락은 블록된 프로세스가 다른 작업을 위해 CPU에 대한 잠금 해제를 허용합니다. 이는 동시성과 가용성에 도움이 됩니다. 당장은 서브 시스템 잠금과 정교한 튜닝을 더 진행하기 전에는 실제 보다 나은 성능을 제공한다고 말하기 어렵습니다.
리눅스 SMP의 접근 방법은 스레드 동기화에 주로 스핀락을 사용하는 것으로 보입니다. 이러한 방법은 코드를 잠그는 것이 비교적 쉽고, 이해하기 쉽다는 장점이 있지만, 다른 작업을 수행할 때 스피닝을 수행하기 때문에 CPU가 시간을 낭비하게 됩니다. 슬립락을 주로 사용하는 리눅스는 인터럽트를 블록하는 반면 락은 유지되고, latency는 증가합니다. 리눅스에서 이러한 문제를 해결하기 위해 커널 선점을 구현하는 작업이 진행되고 있으며, 이는 종종 논란과 문제의 단초가 되고 있습니다.
코드와 아이디어의 일부는 BSD/OS 5에서 얻은 것처럼 보입니다. FreeBSD로 옮기면서 얼마나 많은 것들이 되었나요?
스캇: WITNESS와 같은 락 디버깅 시스템처럼 일부 서브 시스템은 주로 BSD/OS에서 얻은 것입니다. 그러나, 대부분의 다른 작업들은 독립적으로 진행된 것이며, 둘 간에는 공유하는 것은 개념적인 것 뿐입니다.
FreeBSD 사용자가 그러한 코드에 대해 미래에 라이선스, 저작권, 특허권 문제에 휘말릴 가능성이 있습니까?
스캇: 코드 공유는 BSDi 안에서 확실한 협정하에 진행된 것이며, Wind River Systems가 코드 공유를 허락했습니다.
커널 레벨 해킹 외에 무슨 작업들이 필요했습니까?
스캇: SMPng는 주로 커널에 대한 것입니다. 새로운 KSE 스레딩 패키지는 SMPng를 이용한 것이지만, SMPng에 필수적인 부분은 아닙니다.
KSE(Kernel Scheduler Entities)는 SMPng와 어떻게 상호작용을 합니까?
스캇: KSE는 1990년대 워싱턴대학에서 했던 Scheduler Activation에서 파생된 것입니다. 이것은 유저랜드에서 모든 스레딩을 처리하던 고전적인 "libc_r" pthread 라이브러리이며, 이것을 프로세스에 있는 도양한 스레드들이 동시에 여러 CPU를 사용할 수 있게 하기 위해 커널과 유저 랜드간의 스레드 관리와 스케줄링을 공유하는 모델로 대체한 것입니다. 이것은 커널에서 블록을 수행하는 스레드 하나가 프로세스에 있는 모든 스레드를 블록시켜버리는 문제를 해결합니다.
libc_r에서는 멀티 스레드 응용 프로그램은 오직 하나의 CPU만 계속 사용해서 수행될 수 있습니다. 왜냐하면 libc_r은 유저랜드의 모든 스레드를 커널에서 하나의 스케줄링 엔티티로 다중분할하기 때문입니다. KSE에서는 다중분할하는 유저랜드 스케줄러에 다중 스케줄링 엔티티를 제공합니다. 즉, 진정한 병행성을 사용할 수 있다는 것을 의미합니다. 물론, 이것은 이미 "LinuxThreads" 패키지에서 사용할 수 있던 것이지만, 이 패키지는 KSE보다 훨씬 무겁습니다.
SMPng를 위해 ULE 스케줄러가 소개된 것입니까?
스캇: ULE 스케줄러는 과부하시 상호작용성을 증가시키고, CPU를 보다 효율적으로 스케줄링하고, 우선순위를 부여하기 위해 개발된 것입니다. ULE 스케줄러는 또한 복잡한 CPU 토폴로지내에서 보다 복잡한 스케줄링 알고리즘을 사용하기 위한 연구 단계에 있습니다.
ULE 스케줄러는 2004년 도에는 기본 패키지였지만, 5.3 릴리스에서는 사용하지 않습니다. 이유는 이것은 많은 잠재적인 문제들을 갖고 있으며, 잘 유지되지 않는 상태에 있으며, 일부 심각한 안정성 문제를 일으킬 수 있습니다. Jeff Roberson은 문제를 조사하기 시작했으며, 보고된 것들에 대해 변경작업을 하고 있습니다. 다행히도, 미래에는 다시 기본 패키지가 될 것입니다.
질문으로 돌아가서, ULE 스케줄러는 다중 CPU를 최대한 바쁘게 만들어서 보다 열심히 일하게 고안된 것입니다. 전통적인 4BSD 스케줄러에서는, CPU가 idle 상태일때 다음 클럭 틱까지 idle 상태로 있었습니다. 일반적으로 10ms 정도입니다. 이 시간동안 인터럽트가 발생하면, 인터럽트를 서비스하기 위해 스케줄하기 위해 ithread(인터럽트 스레드: 디바이스 드라이버 인터럽트 처리를 배타적으로 처리하는 커널 스레드)가 필요하지만, idle 상태에 있는 CPU는 다음 틱까지 인터럽트를 처리하지 않ㅅㅂ니다. ULE 디자인은 이 문제를 해결하는데 중점을 두고 있습니다.
이것은 실제로 최근의 4BSD 스케줄러에서 IPI wakeup 메커니즘에서 해결된 것입니다. 이를 이용해서 스케줄러는 idle CPU에 wakeup interrupt(IPI)를 보냄으로서 스케줄된 스레드를 실행하고 제거할 수 있습니다. 이 기능은 5.3에서 사용할 수 있습니다.
ULE의 다른 디자인 목표는 맵을 작성하고 CPU 토폴로지를 이해하고, HyperThreading의 기능과 같이 좋은 스케줄링을 선택하게 만드는 것입니다.
불행히도, 내 지식으로는 이 작업이 아직 완벽하지 않습니다.
SMPng는 인텔의 하이퍼 스레딩 CPU에서 수행성능이 향상됩니까?
스캇: 지금 당장은 거의 향상되지 않습니다. 스케줄러는 실제로 하이퍼 스레딩을 인지할 수 있어야하며, 캐시와 TLB가 공유되고 스레쉬 되지 않도록 스레드와 프로세스를 적절하게 스케줄할 필요가 있습니다. ULE 스케줄러는 앞으로 이 역할을 채워갈 것이지만, 아직은 구현되지 않았습니다.
현재 CPU는 종종 1, 2M에 달하는 큰 L2 캐시를 갖고 있습니다. SMPng는 캐시 친화도(affinity)를 얻기 위해 CPU간에 로드를 공유할 수 있습니까?
스캇: FreeBSD 스케줄러는 상당히 구식이며, CPU 토폴로지를 완벽하게 최적화하지 않습니다. 이에 대한 작업이 진행중입니다.
인텔과 AMD가 듀얼 코어 CPU를 곧 판매할 예정입니다. 듀얼 코어 CPU를 이미 받아보셨나요?
스캇: 이 프로젝트는 아직까지 보다 향상된 하드웨어를 받아본적이 없지만, 우리는 인텔 및 AMD와 밀접한 관계를 유지하고 있으며, 앞으로 하드웨어를 갖게 되기를 희망하고 있습니다. 옵테론은 여전히 개발중이지만, AMD는 프로젝트의 다양한 그룹에게 개발 하드웨어를 대여해주는 것에 매우 관대했습니다.
SMPng는 어떤 한계를 갖고 있습니까? 몇 개의 CPU를 지원할 수 있습니까?
스캇: x86과 AMD63에서 표준 인텔 MP 제한인 8개 CPU를 지원합니다. CPU를 추가하는 것처럼 수행성능이 스케일되지 않지만, 가까운 미래에는 논의하게 될 것입니다.
FreeBSD/ia64는 여전히 성숙 단계에 있으며, 불행히도 SMP 환경에서 안정적이지 않습니다. 따라서, 그에 대한 가용성을 논의하는 것은 불가능합니다. Sparc64 포트는 전형적으로 1-4개의 CPU를 갖는 대부분의 Ultra, Netra, Blade 제품군에서 잘 돌아갑니다.(UltraSparc III 시리즈는 제외하고) 보다 높은 시스템에서 이것을 사용하고 있는 사람을 모릅니다.
SMPng 가용성을 벤치마킹해보셨습니까? 2개의 CPU를 추가할 때 마다 성능이 얼마나 향상되는지 알고 싶습니다.
스캇: SMPng가 지금까지 집중한 부분은 정확성에 있습니다. 이것이 항상 보다 나은 가용성이 되는 것은 아니지만, 장기간에 걸친 성공을 위해서는 필요한 것입니다. 현재, 보다 많은 것들이 locked 상태에 있으며, 정확성이 검증되었습니다. 우리의 관심사를 성능과 가용성에 중점을 둘 것입니다. 상당한 성능상의 이점을 얻어낸 것처럼 5.3은 이런점에서 큰 릴리스에 해당합니다. 5.3 이후의 릴리스에서 성능과 가용성면에서 향상될 것이라 기대합니다.
SMPng가 단일 CPU 시스템의 수행성능을 악화시킵니까?
스캇: 이 문제를 해결하기 위해 매우 열심히 노력하고 있습니다. 지금까지 UP 성능이 다소 감소하지만, 잠금을 최적화해감에 따라 보다 나아질 것입니다. SMPng는 커널 선점과 프로세스의 우선 순위 역전에 대한 지연시간 감소와 같은 많은 작업을 포함하고 있습니다. 따라서, 최종 결과물은 UP시에도 보다 반응성이 좋은 시스템이 될 것입니다.
보다 향상될 수 있는 여지가 많습니다. 5.3은 SMPng을 현실에 내놓은 최초의 마일스톤입니다. 네트워크 스택 잠금이 주로 수행되는 환경에서, 많은 노력들이 UP와 SMP 모두에서 성능을 향상시키고 측정하는 것으로 옮겨졌습니다. 이것은 잠금 비용 측정, 가능한한 잠금을 피하는 코드 플로우 최적화, 가능한한 잠금 비용을 줄이기 위한 데이터 플로우 배치와 같은 것들을 포함하고 있습니다. 5.4와 그 이후의 버전들은 분명 이러한 작업들의 이점을 누릴 것입니다.
단일 CPU 환경에서 SMPng없이 커널을 빌드할 수 있습니까?
스캇: SMPng는 5.x의 기초 디자인에 해당하기 때문에 컴파일시에 제거할 수 없습니다. 커널은 SMP 또는 UP로 컴파일 될 수 있으며, UP 설정에서는 잠금의 비용을 삭제할 수 있습니다. 기본 설정은 호환성을 최고로 한 SMP입니다.
FreeBSD 5는 4.x 보다 많은 플랫폼을 지원합니다. 이에 따라, SMPng 코드에 큰 차이가 있습니까?
스캇: 최소 단위 연산(atomic operation)과 잠금 기본요소(locking primitives)에 몇가지 차이점이 있지만, 이들 기본 요소에서 제공하는 API는 커널의 나머지 부분에서 일관성을 갖습니다. 프로그래머가 API를 올바르게 따르는 한, 코드는 제대로 동작할 것이며, 다른 플랫폼에서도 동일하게 동작할 것입니다.
64비트 플랫폼에 대한 최적화가 수행됐습니까?
스캇: 64 비트 CPU가 보다 빨리 실행될 수 있게 하기 위해 가상 메모리 관리에서 최적화가 수행되었습니다.
busdma project와 SMPng간에 유사한 것이 있습니까?
스캇: 전혀 없습니다. busdma는 드라이버가 수정없이 i386 이외의 아키텍처에서 실행될 수 있도록 드라이버/하드웨어 DMA 동작을 추상화한 API입니다. ARM, MIPS, sparc64는 주변 장치를 이용하기 위해 호스트 메모리를 만드는 것이 필요한 특별한 아키텍처들입니다.
busdma API는 드라이버를 올바르게 잠그기 위해 따라야만 하는 프로그래밍 요구사항들을 갖고 있습니다. 이 때문에, API에 대한 드라이버 호환성 알림과 그것을 잠그는 것이 하나의 단일 페이지로 구성되어 있습니다.
가정에서 KDE/GNOME을 비롯해 다른 일반적인 응용프로그램들을 사용하는 듀얼 CPU 웍스테이션을 가진 사용자를 생각해봅시다. 4.10에서 5.3으로 옮길 때 그는 어떤 경험들을 하게 될까요?
스캇: 스레드된 프로세스의 보다 나은 상호작용성, 프로세스와 입력 디바이스간에 보다 나은 상호 작용성과 응답성. 오디오와 비디오 스트리밍 작업을 사용할 때 보다 나은 시스템 수행성능을 보여주게 될 것입니다.
사용자는 언제 FreeBSD 5.3을 설치해야하며, 어떤 눈에 보이는 변화가 있습니까? 이제는 ps 명령어를 사용하면 각 인터럽트가 사용한 시간을 측정할 수 있게 되었다는 것은 읽었습니다. 그외 다른 점은 없습니까?
스캇: /bin과 /sbin 디렉터리에 있는 모든 바이너리들은 이제 동적으로 링크됩니다. /rescue 디렉터리는 중요한 바이너리들에 대해 정적 링크로 컴파일된 사본을 갖고 있으며, 공유 라이브러리 문제 등으로 망가진 시스템을 복구하기 위해 사용할 수 있습니다.
ps와 top은 적절한 플래그를 사용하면 프로세스에 있는 각 스레드의 통계를 보여줍니다.(스크립트에서 이 기능을 올바르게 처리하지 못하는 경우가 있을지도 모르기 때문에 기본설정은 사용하지 않음(off)입니다.) top에서 인터럽트 타임 카운터는 ithread와 저수준(low-level) 인터럽터 핸들러에서 사용된 시간을 보여줍니다.
커널과 모듈은 / 대신에 /boot에 저장됩니다. 로더는 /boot/kernel를 기본 디렉터리로 검색합니다. 로더는 싱글 유저로 부팅하거나 다양한 옵션을 사용하지 않는 상태로 부팅하기와 같은 간단한 메뉴를 사용할 수 있게 되었습니다.
전원 관리는 이제 근본적으로 다릅니다. ACPI가 APM보다 선호되고 있으며, 대부분의 포트들이 ACPI를 사용하고 있지만, 일부 구형 포트는 아직 ACPI로 전환되지 않았습니다.
PCCard 주변 장치는 기존의 pccard 서브 시스템 대신에 cardbus 서브 시스템에서 처리합니다. 구형 pccard 서브 시스템은 마이그레이션 목적으로만 남아있으며, 현재 대부분의 코드가 관리되지 않고 있습니다. cardbus 서브 시스템에 32비타 카드는 네이티브로 동작할 수 있으며, 16비트 카드도 계속 사용할 수 있습니다.
5.3 릴리스는 멀티 스레드 네트워크 스택을 포함합니다. 다른 서브 시스템의 리엔지니어링도 준비된게 있습니까?
스캇: GEOM 스토리지 레이어는 5.x에서 처음 소개된 것이며, 기본적으로 멀티 스레드입니다. 이를 사용하여 스토리지 드라이버, RAID 모듈, 다른 데이터 변환은 Giant 잠금없이 동작할 수 있으며, SMP를 인식할 수 있습니다.
유닉스 파이프와 도메인 소켓은 Giant 잠금 없이 동작할 수 있으며, IPC 통신을 매우 효율적으로 처리할 수 있습니다. SMP를 인지할 수 있게 하기 위해 VM 시스템이 하부에서 꽤 많은 작업을 처리합니다. 결과적으로 커널의 전반적인 부분에서 작은 개선이 상당히 이루어졌습니다.
PF, IFP, IPFW와 같은 패킷 필터링에 대해서 SMPng에서 차이가 나는게 있습니까?
스캇: 방화벽을 기반으로 하는 포워딩과 라우팅은 Giant 뮤텍스나 별도의 CPU 없이 커널에서 수행되기 때문에 어느 정도 향상될 것입니다.
유일하게 Giant 잠금없이 실행할 수 있는 것은 PF 필터 뿐입니다. PF 필터는 OpenBSD에서 수년전에 개발된 것과 같은 코드베이스에서 나온 것이며, FreeBSD에서 가장 활발하게 개발되는 것입니다. Giant 잠금을 사용하지 않기 때문에 세가지 패킷 필터링중에 가장 빠른 필터링이 될 가능성이 있습니다.
IPFW는 FreeBSD에서 수년전에 독자적으로 개발한 패킷 필터로 가장 많은 사람들이 사용하는 것입니다. IPFW는 IPFW2가 나올 것입니다. IP6FW는 IPv6 버전입니다. IPFW 패키지의 좋은 기능은 "dummynet" 입니다. dummynet을 사용하면 어떤 네트워크 인터페이스 에서든 간단한 트래픽 쉐이핑과 대역폭 관리를 할 수 있습니다.
IPFiler는 수년전에 IPFW의 대체 패키지로 소개된 것입니다. IPFiler의 개발자는 현재 수행성능을 개선하기 위해 MPSAFE 패치를 하고 있습니다.
SMPng 로드맵에 대해 이야기할 차례입니다. 앞으로 5.x 릴리스에서 무슨 일을 하실 겁니까?
스캇: 5.3 릴리스 이후로, 5.x 시리지는 5-STABLE 레이블을 갖게 될 것이며, 주로 점진적인 기능, 성능 개선 및 버그 픽스에 주력할 것입니다. 새로운 개발은 6-CURRENT 스트림으로 옮길 것이며, 6-CURRENT에서 안정하다고 판단되는 것만을 5-STABLE로 통합하게 될 것입니다. MPSAFE가 되기 위해서는 보다 많은 스토리지 드라이버와 네트워크 드라이버가 필요하다고 예상하며, SCSI나 USB와 같은 주변 장치 시스템들에 대한 드라이버도 필요할 것입니다. 또한, 우리가 할 수 있는 부분에 대해서는 최적화를 할 것입니다.
2월 말에는 5.4 릴리스를 계획하고 있습니다. 5.5 릴리스는 5.4 릴리스 이후로 4개월 정도 걸릴 것 같지만, 여건이 된다면 6.0에 대한 새로운 계획도 세울 것입니다.
토론을 마친후에, 우리는 FreeBSD의 전체 개발 사이클을 빨리 하기로 결정했으며, 매 12-18개월을 기준으로 메이저 릴리스를 발표하고, 메이저 릴리스 사이에 4개월 간격으로 마이너 릴리스를 발표할 것입니다. 즉, 2005년 5월이나 6월에는 6.0에 대한 준비를 시작할 것이며, 그때쯤 RELENG_6 CVS 분기(branch)를 한 후 버그 픽스와 QA에 1-3개월 정도를 보낸 후, 2005년 7-8월 쯤에 6.0을 발표할 것입니다. 이 계획은 그때 그때의 개발에 따라 다르기 때문에 그 보다 더 걸릴 수도 있습니다.
새로운 일정 체계에서 주요 관심사는 보다 안정성 있는 제품을 보다 시의 적절하게 발표하는 것이 될 것입니다. 5.x 개발의 문제점은 우리가 새로운 기능이나 최적화을 위해 각 릴리스를 뒤로 미루는 동안 사용자들은 새 하드웨어에 대한 지원을 기대할 수 없었다는 점입니다.
가장 큰 성능 향상을 이룬 것은 어떤 서브 시스템입니까?
스캇: 지금 가장 많은 역량을 모으고 있는 부분은 네트워크 스택입니다. 이는 네트워크 패킷이 커널을 동시에 양방향으로 소통하는 것을 가능하게 해줄 것이며, 인바운드(inbound) 패킷을 받거나 처리하는 것을 보다 짧은 시간 안에 하게 될 것입니다.
ATA 드라이버를 포함한 몇가지 스토리지 드라이버는 현재 MPSAFE이며, 네트워크 스택에서 얘기한 것과 유사한 이점을 보여줄 것입니다. 파이프, 소켓, VM과 같은 커널 서비스는 현재 MPSAFE입니다.
SMPng의 최종적인 목표는 모든 CPU에 유효 작업을 최대한 이끌어내는 시스템을 갖는 것입니다. 자원에 대한 액세스를 동기화하는 것은 SMP에서 피할 수 없는 비용이기 때문에 현재 작업이 자원을 기다리는 동안 CPU를 다른 작업으로 빠르게 스위칭하는 것에 집중하고 있습니다.
SMPng 작업은 두 개의 잠금 - Giant 슬립 뮤텍스(전체 커널을 담당함)과 스케줄러 스핀락(하드웨어 인터럽트 동안 동기화 제공) -을 사용하여 전체 커널을 보호하는 것으로 시작했습니다. 여기서부터 시작해서 개별 드라이버와 서브 시스템에 대한 잠금을 제공하는 것으로 Giant 잠금의 범위를 줄여왔습니다. 궁극적인 목표는 Giant 잠금을 완전히 제거하는 것입니다.
SMPng에는 누가 일했으며, 누가 일하고 있습니까? 누가 무엇을 했습니까?
스캇: 초기 SMPng 디자인 미팅은 다음 멤버들이 참석했습니다.(Steve Passe"s SMPng page에서 인용): Don Brady, Ramesh?, Ted Walker, Jeffrey Hsu, Chuck Paterson, Jonathan Lemon, Matt Dillon, Paul Saab, Kirk McKusick, Peter Wemm, Jayanth?, Doug Rabson, Jason Evans, David Greenman, Justin Gibbs, Greg Lehey, Mike Smith, Alfred Perlstein, David O"Brien, Ceren Ercen.
Jason Evans는 2001년까지 아키텍처 작업을 이끌었으며, John Baldwin이 이어받았으며 지금까지 작업을 맡아오고 있습니다. SMPng project page에는 SMPng를 위해 일한 많은 사람들의 목록을 게재하고 있습니다.
FreeBSD 5-SABLE에서 멀티 스레드 응용 프로그램을 개발하려는 사람들이 알아야 할 조언은 없습니까? SMPng에서 코드를 최적화할 수 있는 방법을 알려주시겠습니까?
스캇: KSE 스레딩 라이브러리는 pthread 라이브러리를 기본 라이브러리로 사용하고 있습니다. 기존의 libc_r은 디버깅을 보조하기 위한 용도로만 사용되고 있습니다. KSE를 위한 GDB 지원은 발전해나가는 중이기 때문에 디버깅을 위해 libc_r로 전환하는 것이 유용할 때도 있습니다.
지금 당장은 응용 프로그램이 SMPng와 상호작용할 수 있는 방법이 거의 없습니다. 앞으로는 캐시 로컬리티나 병행화를 위해 특정 CPU에 스레드를 그룹으로 묶을 수 있는 방법을 제공할 수도 있습니다.
원문: http://www.onlamp.com/pub/a/bsd/2005/01/20/smpng.html
지난 5년 동안 FreeBSD 개발팀은 멀티 프로세서 시스템의 성능을 향상시키기 위해 많은 노력을 기울여 왔다. FreeBSD 개발팀의 목표는 4.x 대에서 사용되었던 Big Kernel Lock을 제거하고, 보다 정교한 SMP 지원을 제공하는 것이었다. 흔히 SMPng라 언급되는 SMP next generation 프로젝트는 많은 노력이 필요했으며, 안정화 상태에 도달하기 위해 5.0에서 5.3까지 4개의 릴리스를 거쳐와야했다.
역주: Big Kernel Lock: 리눅스의 SMP 지원 초기에 제공되었던 그다지 정교하지 못한 버전의 잠금(Lock) 메커니즘을 의미한다.
페데리코 비안쿠지(Federico Biancuzzi)는 SMPng 기술, 현재 구현 상태, 앞으로의 목표와 계획에 대해 FreeBSD의 코어 멤버인 스캇 롱(Scott Long)과 인터뷰하였다.
소개를 부탁드려도 될까요?
스캇: 저는 30세이며, 결혼한지 7년된 아내와 각각 4살과 6살인 아이들과 함께 콜로라도 주 보울더 근교에서 살고 있습니다. 현재 캐나다 워러투에 있는 Sandvine 회사에서 FreeBSD 시스템 지원을 하고 있습니다. 전에는 거의 5년 동안 Adaptec에서 오픈 소스 그룹의 일원이었습니다. FreeBSD 일을 하지 않을 때는 그리 멀지 않은 산에서 바이킹, 하이킹, 캠핑을 하는 것을 즐깁니다.
역주: 보울더는 콜로라도주 덴버시 북서쪽으로 1시간 정도 떨어진 곳에 위치한 지방
프로젝트에서 맡은 역할은 무엇인가요?
스캇: 저는 FreeBSD 태동기부터 사용해 왔으며, 2000년 이후로는 기여 회원(contributing member)로 있습니다. 현재는 일련의 5.x 릴리스의 릴리스 엔지니어링을 이끌어 가고 있으며, 최근에는 FreeBSD 코어 팀(Core Team)을 제안받았습니다.
제 주요 관심사는 스토리지에 대한 것입니다. 저는 FreeBSD RAID 드라이버의 대부분을 관리하고 있으며, UDF 파일 시스템 지원을 작성했습니다. 최근에는 보다 작고 견고한 USB 드라이버를 몇 개 작성했습니다.
다양한 잠금(Lock)의 차이점을 알지 못하는 독자들을 위해 그것들을 요약해 주시겠습니까?
스캇: 스핀락(spin lock)은 잠금을 할 수 없는 경우 CPU가 중단없이 코드를 빙글빙글 돌면서(역주: 이를 spin한다고 함) 잠금을 획득할 때 까지 반복하는 뮤텍스입니다. CPU는 잠금을 획득하기 전에는 어떤 일도 수행하지 않습니다.
역주: 리눅스에서는 버저락(Buzz Lock)이라고 알려져 있다. 대부분의 CPU에서는 하드웨어적으로 이를 지원하고 있으며, 지원하지 않는 시스템에서는 캐시되지 않는 메인 메모리를 사용하여 이를 구현하고 있다.
슬립 락은 잠금을 이용할 수 없는 경우 현재 스레드나 프로세스를 재웁니다(sleep). 잠금을 획득하고 있는 스레드나 프로세스가 잠금을 해제할 때 이 스레드가 깨어나게 됩니다. 반면에, CPU는 다른 스레드를 실행하기 때문에 Busy 상태가 될 것입니다.
SX 락(shared-exclusive lock)은 여러 스레드가 읽기 상태에 있는 것을 동시에 접근할 수 있게 하지만, 오직 하나의 스레드만 쓰기 상태를 획득할 수 있습니다. 읽기, 쓰기는 잠금에 의해 보호되는 리소스에 의해 수행되는 동작을 의미합니다.
역주: 주로 reader-writer lock 또는 provider-consumer lock으로 알려져 있다.
블로킹(blocking)은 슬리핑(sleeping)과 동의어 입니다. 스레드가 블록될 때, 스레드를 스케줄러의 슬립 큐(sleep queue)에 넣고, 잠금 해제와 같은 이벤트가 발생할 때 까지 슬립큐에 대기하게 됩니다.
세마포어 세기(Counting semaphores)도 사용할 수 있습니다. 이것은 잠금을 동시에 획득하기 위해 예정된 수 만큼의 스레드를 허용하는 형태의 슬립 락입니다.
FreeBSD 4 SMP는 어떻게 동작합니까?
스캇: SMP를 구현하는 전형적인 방법은 userland 프로세스를 동시에 실행하는 것이지만, 오직 한 CPU만 한 번에 커널 안에 있을 수 있습니다. 이것을 커널에 대한 진입을 제한하는 스핀 락, 즉 "mplock"에서 수행됩니다.
이러한 구현이 갖는 문제점은 무엇입니까?
스캇: 이러한 접근 방법은 주로 유저랜드에서 실행되거나 계산만 수행하는 작업부하에 대해서는 잘 동작하지만 과도한 I/O, 네트워크, 커널 서비스에 대한 작업 부하에 대해서는 매우 취약합니다.
FreeBSD 5 SMPng에서는 이 문제를 어떻게 해결했나요?
스캇: FreeBSD 5에서 mplock은 제거되었습니다. mplock 대신에 대양한 커널 서비스들이 동기화와 다중 프로세서 안정성을 허용하는 일련의 잠금과 동기성 기본요소(synchronization primitives)가 사용됩니다. 여러 프로세스가 동시에 커널에 머무를 수 있습니다.
두번째 큰 변화는 인터럽트 스레드라 불리는 특별한 커널 프로세스 컨텍스트에서 대부분의 작업을 수행합니다. 인터럽트 스레드를 사용하면 드라이버가 슬리핑동안에 전체 CPU를 블로킹하지 않고 인터럽트 핸들러의 슬립 락을 사용할 수 있습니다.
명확하게 MPSAFE로 되어있지 않은 부분, 즉 "Giant"라 불리는 글로벌 뮤텍스가 존재하며, 이것은 4.x대의 mplock과 비슷한 방식으로 보호를 수행합니다. 따라서, 현재 기본적인 목표는 기존 코드를 MPSAFE로 만드는 것과 최대한 Giant를 제거해 나가는 것입니다.
인터럽트 스레드는 무엇입니까?
스캇: 인터럽트 스레드는 커널안에 머무르는 일반 스레드입니다. 이 스레드의 유일한 목적은 드라이버 인터럽트 핸들러에 실행 컨텍스트를 제공하는 것입니다. 인트럽트 스레드를 사용하면 드라이버가 리소스에 대한 블록이나 잠금과 같은 전형적인 인터럽트 컨텍스트에서 허용되지 않던 작업들을 수행할 수 있습니다.
전형적인 인터럽트 컨텍스트는 ithread를 스케줄하기 위해 사용합니다. latency에 영향을 받으며, 블로킹을 사용하지 않는 일부 드라이버는 인터럽트 컨텍스트에서 직접 인터럽트 핸들러를 수행할 수 있으며, ithread를 사용하지 않을 수 있습니다. 그러나, 이것은 매우 특별한 경우에 해당합니다.
DragonFlyBSD의 SMP 기술에 대해 어떻게 생각하십니까? SMPng와 어떤 점이 다른가요?
스캇: DragonFly의 방법은 공유 데이터 구조에 대한 액세스를 동기화하는 방법 대신 서브 시스템간에 메시지를 주고 받는 방식으로 동시성을 구현하는 방법은 Mach나 AmigaOS에서 사용된 것과 매우 비슷해 보입니다. DragonFly의 작업은 아직 유아기에 머물러 있지만, 계속 주시할 것이며, 어떻게 발전해 가는지 지켜볼 것입니다.
NetBSD/OpenBSD SMP는 어떻습니까?
스캇: 저는 OpenBSD에 익숙하지 않지만, NetBSD는 FreeBSD 4.x와 같은 접근방법을 사용하고 있는 것으로 보입니다. 최근 벤치마크에 따르면 NetBSD 2.0이 FreeBSD 5.x보다 빠르다고 합니다. 여기서 실시한 테스트 결과에 따르면 FreeBSD가 대부분 보다 높은 수치에서 끝났습니다. 이것들은 FreeBSD 5.x의 SMPng 잠금의 비용을 보여주고 있습니다. 당장 이 문제를 해결하기에는 작업이 많은 편입니다.
FreeBSD SMPng는 리눅스 SMP보다 나은 성능을 보여줄 수 있을까요?
스캇: SMPng 설계 목표중에 하나는 스핀 락 대신에 슬립 락 사용을 활성화하는 것입니다. 슬립 락은 블록된 프로세스가 다른 작업을 위해 CPU에 대한 잠금 해제를 허용합니다. 이는 동시성과 가용성에 도움이 됩니다. 당장은 서브 시스템 잠금과 정교한 튜닝을 더 진행하기 전에는 실제 보다 나은 성능을 제공한다고 말하기 어렵습니다.
리눅스 SMP의 접근 방법은 스레드 동기화에 주로 스핀락을 사용하는 것으로 보입니다. 이러한 방법은 코드를 잠그는 것이 비교적 쉽고, 이해하기 쉽다는 장점이 있지만, 다른 작업을 수행할 때 스피닝을 수행하기 때문에 CPU가 시간을 낭비하게 됩니다. 슬립락을 주로 사용하는 리눅스는 인터럽트를 블록하는 반면 락은 유지되고, latency는 증가합니다. 리눅스에서 이러한 문제를 해결하기 위해 커널 선점을 구현하는 작업이 진행되고 있으며, 이는 종종 논란과 문제의 단초가 되고 있습니다.
코드와 아이디어의 일부는 BSD/OS 5에서 얻은 것처럼 보입니다. FreeBSD로 옮기면서 얼마나 많은 것들이 되었나요?
스캇: WITNESS와 같은 락 디버깅 시스템처럼 일부 서브 시스템은 주로 BSD/OS에서 얻은 것입니다. 그러나, 대부분의 다른 작업들은 독립적으로 진행된 것이며, 둘 간에는 공유하는 것은 개념적인 것 뿐입니다.
FreeBSD 사용자가 그러한 코드에 대해 미래에 라이선스, 저작권, 특허권 문제에 휘말릴 가능성이 있습니까?
스캇: 코드 공유는 BSDi 안에서 확실한 협정하에 진행된 것이며, Wind River Systems가 코드 공유를 허락했습니다.
커널 레벨 해킹 외에 무슨 작업들이 필요했습니까?
스캇: SMPng는 주로 커널에 대한 것입니다. 새로운 KSE 스레딩 패키지는 SMPng를 이용한 것이지만, SMPng에 필수적인 부분은 아닙니다.
KSE(Kernel Scheduler Entities)는 SMPng와 어떻게 상호작용을 합니까?
스캇: KSE는 1990년대 워싱턴대학에서 했던 Scheduler Activation에서 파생된 것입니다. 이것은 유저랜드에서 모든 스레딩을 처리하던 고전적인 "libc_r" pthread 라이브러리이며, 이것을 프로세스에 있는 도양한 스레드들이 동시에 여러 CPU를 사용할 수 있게 하기 위해 커널과 유저 랜드간의 스레드 관리와 스케줄링을 공유하는 모델로 대체한 것입니다. 이것은 커널에서 블록을 수행하는 스레드 하나가 프로세스에 있는 모든 스레드를 블록시켜버리는 문제를 해결합니다.
libc_r에서는 멀티 스레드 응용 프로그램은 오직 하나의 CPU만 계속 사용해서 수행될 수 있습니다. 왜냐하면 libc_r은 유저랜드의 모든 스레드를 커널에서 하나의 스케줄링 엔티티로 다중분할하기 때문입니다. KSE에서는 다중분할하는 유저랜드 스케줄러에 다중 스케줄링 엔티티를 제공합니다. 즉, 진정한 병행성을 사용할 수 있다는 것을 의미합니다. 물론, 이것은 이미 "LinuxThreads" 패키지에서 사용할 수 있던 것이지만, 이 패키지는 KSE보다 훨씬 무겁습니다.
SMPng를 위해 ULE 스케줄러가 소개된 것입니까?
스캇: ULE 스케줄러는 과부하시 상호작용성을 증가시키고, CPU를 보다 효율적으로 스케줄링하고, 우선순위를 부여하기 위해 개발된 것입니다. ULE 스케줄러는 또한 복잡한 CPU 토폴로지내에서 보다 복잡한 스케줄링 알고리즘을 사용하기 위한 연구 단계에 있습니다.
ULE 스케줄러는 2004년 도에는 기본 패키지였지만, 5.3 릴리스에서는 사용하지 않습니다. 이유는 이것은 많은 잠재적인 문제들을 갖고 있으며, 잘 유지되지 않는 상태에 있으며, 일부 심각한 안정성 문제를 일으킬 수 있습니다. Jeff Roberson은 문제를 조사하기 시작했으며, 보고된 것들에 대해 변경작업을 하고 있습니다. 다행히도, 미래에는 다시 기본 패키지가 될 것입니다.
질문으로 돌아가서, ULE 스케줄러는 다중 CPU를 최대한 바쁘게 만들어서 보다 열심히 일하게 고안된 것입니다. 전통적인 4BSD 스케줄러에서는, CPU가 idle 상태일때 다음 클럭 틱까지 idle 상태로 있었습니다. 일반적으로 10ms 정도입니다. 이 시간동안 인터럽트가 발생하면, 인터럽트를 서비스하기 위해 스케줄하기 위해 ithread(인터럽트 스레드: 디바이스 드라이버 인터럽트 처리를 배타적으로 처리하는 커널 스레드)가 필요하지만, idle 상태에 있는 CPU는 다음 틱까지 인터럽트를 처리하지 않ㅅㅂ니다. ULE 디자인은 이 문제를 해결하는데 중점을 두고 있습니다.
이것은 실제로 최근의 4BSD 스케줄러에서 IPI wakeup 메커니즘에서 해결된 것입니다. 이를 이용해서 스케줄러는 idle CPU에 wakeup interrupt(IPI)를 보냄으로서 스케줄된 스레드를 실행하고 제거할 수 있습니다. 이 기능은 5.3에서 사용할 수 있습니다.
ULE의 다른 디자인 목표는 맵을 작성하고 CPU 토폴로지를 이해하고, HyperThreading의 기능과 같이 좋은 스케줄링을 선택하게 만드는 것입니다.
불행히도, 내 지식으로는 이 작업이 아직 완벽하지 않습니다.
SMPng는 인텔의 하이퍼 스레딩 CPU에서 수행성능이 향상됩니까?
스캇: 지금 당장은 거의 향상되지 않습니다. 스케줄러는 실제로 하이퍼 스레딩을 인지할 수 있어야하며, 캐시와 TLB가 공유되고 스레쉬 되지 않도록 스레드와 프로세스를 적절하게 스케줄할 필요가 있습니다. ULE 스케줄러는 앞으로 이 역할을 채워갈 것이지만, 아직은 구현되지 않았습니다.
현재 CPU는 종종 1, 2M에 달하는 큰 L2 캐시를 갖고 있습니다. SMPng는 캐시 친화도(affinity)를 얻기 위해 CPU간에 로드를 공유할 수 있습니까?
스캇: FreeBSD 스케줄러는 상당히 구식이며, CPU 토폴로지를 완벽하게 최적화하지 않습니다. 이에 대한 작업이 진행중입니다.
인텔과 AMD가 듀얼 코어 CPU를 곧 판매할 예정입니다. 듀얼 코어 CPU를 이미 받아보셨나요?
스캇: 이 프로젝트는 아직까지 보다 향상된 하드웨어를 받아본적이 없지만, 우리는 인텔 및 AMD와 밀접한 관계를 유지하고 있으며, 앞으로 하드웨어를 갖게 되기를 희망하고 있습니다. 옵테론은 여전히 개발중이지만, AMD는 프로젝트의 다양한 그룹에게 개발 하드웨어를 대여해주는 것에 매우 관대했습니다.
SMPng는 어떤 한계를 갖고 있습니까? 몇 개의 CPU를 지원할 수 있습니까?
스캇: x86과 AMD63에서 표준 인텔 MP 제한인 8개 CPU를 지원합니다. CPU를 추가하는 것처럼 수행성능이 스케일되지 않지만, 가까운 미래에는 논의하게 될 것입니다.
FreeBSD/ia64는 여전히 성숙 단계에 있으며, 불행히도 SMP 환경에서 안정적이지 않습니다. 따라서, 그에 대한 가용성을 논의하는 것은 불가능합니다. Sparc64 포트는 전형적으로 1-4개의 CPU를 갖는 대부분의 Ultra, Netra, Blade 제품군에서 잘 돌아갑니다.(UltraSparc III 시리즈는 제외하고) 보다 높은 시스템에서 이것을 사용하고 있는 사람을 모릅니다.
SMPng 가용성을 벤치마킹해보셨습니까? 2개의 CPU를 추가할 때 마다 성능이 얼마나 향상되는지 알고 싶습니다.
스캇: SMPng가 지금까지 집중한 부분은 정확성에 있습니다. 이것이 항상 보다 나은 가용성이 되는 것은 아니지만, 장기간에 걸친 성공을 위해서는 필요한 것입니다. 현재, 보다 많은 것들이 locked 상태에 있으며, 정확성이 검증되었습니다. 우리의 관심사를 성능과 가용성에 중점을 둘 것입니다. 상당한 성능상의 이점을 얻어낸 것처럼 5.3은 이런점에서 큰 릴리스에 해당합니다. 5.3 이후의 릴리스에서 성능과 가용성면에서 향상될 것이라 기대합니다.
SMPng가 단일 CPU 시스템의 수행성능을 악화시킵니까?
스캇: 이 문제를 해결하기 위해 매우 열심히 노력하고 있습니다. 지금까지 UP 성능이 다소 감소하지만, 잠금을 최적화해감에 따라 보다 나아질 것입니다. SMPng는 커널 선점과 프로세스의 우선 순위 역전에 대한 지연시간 감소와 같은 많은 작업을 포함하고 있습니다. 따라서, 최종 결과물은 UP시에도 보다 반응성이 좋은 시스템이 될 것입니다.
보다 향상될 수 있는 여지가 많습니다. 5.3은 SMPng을 현실에 내놓은 최초의 마일스톤입니다. 네트워크 스택 잠금이 주로 수행되는 환경에서, 많은 노력들이 UP와 SMP 모두에서 성능을 향상시키고 측정하는 것으로 옮겨졌습니다. 이것은 잠금 비용 측정, 가능한한 잠금을 피하는 코드 플로우 최적화, 가능한한 잠금 비용을 줄이기 위한 데이터 플로우 배치와 같은 것들을 포함하고 있습니다. 5.4와 그 이후의 버전들은 분명 이러한 작업들의 이점을 누릴 것입니다.
단일 CPU 환경에서 SMPng없이 커널을 빌드할 수 있습니까?
스캇: SMPng는 5.x의 기초 디자인에 해당하기 때문에 컴파일시에 제거할 수 없습니다. 커널은 SMP 또는 UP로 컴파일 될 수 있으며, UP 설정에서는 잠금의 비용을 삭제할 수 있습니다. 기본 설정은 호환성을 최고로 한 SMP입니다.
FreeBSD 5는 4.x 보다 많은 플랫폼을 지원합니다. 이에 따라, SMPng 코드에 큰 차이가 있습니까?
스캇: 최소 단위 연산(atomic operation)과 잠금 기본요소(locking primitives)에 몇가지 차이점이 있지만, 이들 기본 요소에서 제공하는 API는 커널의 나머지 부분에서 일관성을 갖습니다. 프로그래머가 API를 올바르게 따르는 한, 코드는 제대로 동작할 것이며, 다른 플랫폼에서도 동일하게 동작할 것입니다.
64비트 플랫폼에 대한 최적화가 수행됐습니까?
스캇: 64 비트 CPU가 보다 빨리 실행될 수 있게 하기 위해 가상 메모리 관리에서 최적화가 수행되었습니다.
busdma project와 SMPng간에 유사한 것이 있습니까?
스캇: 전혀 없습니다. busdma는 드라이버가 수정없이 i386 이외의 아키텍처에서 실행될 수 있도록 드라이버/하드웨어 DMA 동작을 추상화한 API입니다. ARM, MIPS, sparc64는 주변 장치를 이용하기 위해 호스트 메모리를 만드는 것이 필요한 특별한 아키텍처들입니다.
busdma API는 드라이버를 올바르게 잠그기 위해 따라야만 하는 프로그래밍 요구사항들을 갖고 있습니다. 이 때문에, API에 대한 드라이버 호환성 알림과 그것을 잠그는 것이 하나의 단일 페이지로 구성되어 있습니다.
가정에서 KDE/GNOME을 비롯해 다른 일반적인 응용프로그램들을 사용하는 듀얼 CPU 웍스테이션을 가진 사용자를 생각해봅시다. 4.10에서 5.3으로 옮길 때 그는 어떤 경험들을 하게 될까요?
스캇: 스레드된 프로세스의 보다 나은 상호작용성, 프로세스와 입력 디바이스간에 보다 나은 상호 작용성과 응답성. 오디오와 비디오 스트리밍 작업을 사용할 때 보다 나은 시스템 수행성능을 보여주게 될 것입니다.
사용자는 언제 FreeBSD 5.3을 설치해야하며, 어떤 눈에 보이는 변화가 있습니까? 이제는 ps 명령어를 사용하면 각 인터럽트가 사용한 시간을 측정할 수 있게 되었다는 것은 읽었습니다. 그외 다른 점은 없습니까?
스캇: /bin과 /sbin 디렉터리에 있는 모든 바이너리들은 이제 동적으로 링크됩니다. /rescue 디렉터리는 중요한 바이너리들에 대해 정적 링크로 컴파일된 사본을 갖고 있으며, 공유 라이브러리 문제 등으로 망가진 시스템을 복구하기 위해 사용할 수 있습니다.
ps와 top은 적절한 플래그를 사용하면 프로세스에 있는 각 스레드의 통계를 보여줍니다.(스크립트에서 이 기능을 올바르게 처리하지 못하는 경우가 있을지도 모르기 때문에 기본설정은 사용하지 않음(off)입니다.) top에서 인터럽트 타임 카운터는 ithread와 저수준(low-level) 인터럽터 핸들러에서 사용된 시간을 보여줍니다.
커널과 모듈은 / 대신에 /boot에 저장됩니다. 로더는 /boot/kernel를 기본 디렉터리로 검색합니다. 로더는 싱글 유저로 부팅하거나 다양한 옵션을 사용하지 않는 상태로 부팅하기와 같은 간단한 메뉴를 사용할 수 있게 되었습니다.
전원 관리는 이제 근본적으로 다릅니다. ACPI가 APM보다 선호되고 있으며, 대부분의 포트들이 ACPI를 사용하고 있지만, 일부 구형 포트는 아직 ACPI로 전환되지 않았습니다.
PCCard 주변 장치는 기존의 pccard 서브 시스템 대신에 cardbus 서브 시스템에서 처리합니다. 구형 pccard 서브 시스템은 마이그레이션 목적으로만 남아있으며, 현재 대부분의 코드가 관리되지 않고 있습니다. cardbus 서브 시스템에 32비타 카드는 네이티브로 동작할 수 있으며, 16비트 카드도 계속 사용할 수 있습니다.
5.3 릴리스는 멀티 스레드 네트워크 스택을 포함합니다. 다른 서브 시스템의 리엔지니어링도 준비된게 있습니까?
스캇: GEOM 스토리지 레이어는 5.x에서 처음 소개된 것이며, 기본적으로 멀티 스레드입니다. 이를 사용하여 스토리지 드라이버, RAID 모듈, 다른 데이터 변환은 Giant 잠금없이 동작할 수 있으며, SMP를 인식할 수 있습니다.
유닉스 파이프와 도메인 소켓은 Giant 잠금 없이 동작할 수 있으며, IPC 통신을 매우 효율적으로 처리할 수 있습니다. SMP를 인지할 수 있게 하기 위해 VM 시스템이 하부에서 꽤 많은 작업을 처리합니다. 결과적으로 커널의 전반적인 부분에서 작은 개선이 상당히 이루어졌습니다.
PF, IFP, IPFW와 같은 패킷 필터링에 대해서 SMPng에서 차이가 나는게 있습니까?
스캇: 방화벽을 기반으로 하는 포워딩과 라우팅은 Giant 뮤텍스나 별도의 CPU 없이 커널에서 수행되기 때문에 어느 정도 향상될 것입니다.
유일하게 Giant 잠금없이 실행할 수 있는 것은 PF 필터 뿐입니다. PF 필터는 OpenBSD에서 수년전에 개발된 것과 같은 코드베이스에서 나온 것이며, FreeBSD에서 가장 활발하게 개발되는 것입니다. Giant 잠금을 사용하지 않기 때문에 세가지 패킷 필터링중에 가장 빠른 필터링이 될 가능성이 있습니다.
IPFW는 FreeBSD에서 수년전에 독자적으로 개발한 패킷 필터로 가장 많은 사람들이 사용하는 것입니다. IPFW는 IPFW2가 나올 것입니다. IP6FW는 IPv6 버전입니다. IPFW 패키지의 좋은 기능은 "dummynet" 입니다. dummynet을 사용하면 어떤 네트워크 인터페이스 에서든 간단한 트래픽 쉐이핑과 대역폭 관리를 할 수 있습니다.
IPFiler는 수년전에 IPFW의 대체 패키지로 소개된 것입니다. IPFiler의 개발자는 현재 수행성능을 개선하기 위해 MPSAFE 패치를 하고 있습니다.
SMPng 로드맵에 대해 이야기할 차례입니다. 앞으로 5.x 릴리스에서 무슨 일을 하실 겁니까?
스캇: 5.3 릴리스 이후로, 5.x 시리지는 5-STABLE 레이블을 갖게 될 것이며, 주로 점진적인 기능, 성능 개선 및 버그 픽스에 주력할 것입니다. 새로운 개발은 6-CURRENT 스트림으로 옮길 것이며, 6-CURRENT에서 안정하다고 판단되는 것만을 5-STABLE로 통합하게 될 것입니다. MPSAFE가 되기 위해서는 보다 많은 스토리지 드라이버와 네트워크 드라이버가 필요하다고 예상하며, SCSI나 USB와 같은 주변 장치 시스템들에 대한 드라이버도 필요할 것입니다. 또한, 우리가 할 수 있는 부분에 대해서는 최적화를 할 것입니다.
2월 말에는 5.4 릴리스를 계획하고 있습니다. 5.5 릴리스는 5.4 릴리스 이후로 4개월 정도 걸릴 것 같지만, 여건이 된다면 6.0에 대한 새로운 계획도 세울 것입니다.
토론을 마친후에, 우리는 FreeBSD의 전체 개발 사이클을 빨리 하기로 결정했으며, 매 12-18개월을 기준으로 메이저 릴리스를 발표하고, 메이저 릴리스 사이에 4개월 간격으로 마이너 릴리스를 발표할 것입니다. 즉, 2005년 5월이나 6월에는 6.0에 대한 준비를 시작할 것이며, 그때쯤 RELENG_6 CVS 분기(branch)를 한 후 버그 픽스와 QA에 1-3개월 정도를 보낸 후, 2005년 7-8월 쯤에 6.0을 발표할 것입니다. 이 계획은 그때 그때의 개발에 따라 다르기 때문에 그 보다 더 걸릴 수도 있습니다.
새로운 일정 체계에서 주요 관심사는 보다 안정성 있는 제품을 보다 시의 적절하게 발표하는 것이 될 것입니다. 5.x 개발의 문제점은 우리가 새로운 기능이나 최적화을 위해 각 릴리스를 뒤로 미루는 동안 사용자들은 새 하드웨어에 대한 지원을 기대할 수 없었다는 점입니다.
가장 큰 성능 향상을 이룬 것은 어떤 서브 시스템입니까?
스캇: 지금 가장 많은 역량을 모으고 있는 부분은 네트워크 스택입니다. 이는 네트워크 패킷이 커널을 동시에 양방향으로 소통하는 것을 가능하게 해줄 것이며, 인바운드(inbound) 패킷을 받거나 처리하는 것을 보다 짧은 시간 안에 하게 될 것입니다.
ATA 드라이버를 포함한 몇가지 스토리지 드라이버는 현재 MPSAFE이며, 네트워크 스택에서 얘기한 것과 유사한 이점을 보여줄 것입니다. 파이프, 소켓, VM과 같은 커널 서비스는 현재 MPSAFE입니다.
SMPng의 최종적인 목표는 모든 CPU에 유효 작업을 최대한 이끌어내는 시스템을 갖는 것입니다. 자원에 대한 액세스를 동기화하는 것은 SMP에서 피할 수 없는 비용이기 때문에 현재 작업이 자원을 기다리는 동안 CPU를 다른 작업으로 빠르게 스위칭하는 것에 집중하고 있습니다.
SMPng 작업은 두 개의 잠금 - Giant 슬립 뮤텍스(전체 커널을 담당함)과 스케줄러 스핀락(하드웨어 인터럽트 동안 동기화 제공) -을 사용하여 전체 커널을 보호하는 것으로 시작했습니다. 여기서부터 시작해서 개별 드라이버와 서브 시스템에 대한 잠금을 제공하는 것으로 Giant 잠금의 범위를 줄여왔습니다. 궁극적인 목표는 Giant 잠금을 완전히 제거하는 것입니다.
SMPng에는 누가 일했으며, 누가 일하고 있습니까? 누가 무엇을 했습니까?
스캇: 초기 SMPng 디자인 미팅은 다음 멤버들이 참석했습니다.(Steve Passe"s SMPng page에서 인용): Don Brady, Ramesh?, Ted Walker, Jeffrey Hsu, Chuck Paterson, Jonathan Lemon, Matt Dillon, Paul Saab, Kirk McKusick, Peter Wemm, Jayanth?, Doug Rabson, Jason Evans, David Greenman, Justin Gibbs, Greg Lehey, Mike Smith, Alfred Perlstein, David O"Brien, Ceren Ercen.
Jason Evans는 2001년까지 아키텍처 작업을 이끌었으며, John Baldwin이 이어받았으며 지금까지 작업을 맡아오고 있습니다. SMPng project page에는 SMPng를 위해 일한 많은 사람들의 목록을 게재하고 있습니다.
FreeBSD 5-SABLE에서 멀티 스레드 응용 프로그램을 개발하려는 사람들이 알아야 할 조언은 없습니까? SMPng에서 코드를 최적화할 수 있는 방법을 알려주시겠습니까?
스캇: KSE 스레딩 라이브러리는 pthread 라이브러리를 기본 라이브러리로 사용하고 있습니다. 기존의 libc_r은 디버깅을 보조하기 위한 용도로만 사용되고 있습니다. KSE를 위한 GDB 지원은 발전해나가는 중이기 때문에 디버깅을 위해 libc_r로 전환하는 것이 유용할 때도 있습니다.
지금 당장은 응용 프로그램이 SMPng와 상호작용할 수 있는 방법이 거의 없습니다. 앞으로는 캐시 로컬리티나 병행화를 위해 특정 CPU에 스레드를 그룹으로 묶을 수 있는 방법을 제공할 수도 있습니다.
TAG :
이전 글 : VB.NET 2.0과 함께하는 빠른 응용 프로그램 개발
다음 글 : Induction을 이용한 프로그램
최신 콘텐츠