리눅스 SMP 하우투

2.1. 커널 관련

1. 리눅스가 멀티 스레드를 지원하나요? 만약 내가 두개 이상의 프로세스를 실행 시킨다면, 모든 CPU들에 분산 처리가 될까요?

   네, 프로세스와 커널-스레드들은 프로세서들에게 분산될 것입니다, 그러나 유저 스페이스 스레드들은 그렇지 않습니다.

2. 어떤 아키텍처들에서 SMP를 지원 하나요?

   Alan Cox로 부터:

   SMP는 커널 2.0 이상 에서 인텔 MP1.1/1.4 를 지원하는 hypersparc(SS20 또는 그외), 인텔 486, 펜티엄 또는 그 이상에서 작동합니다. Richard Jelinek가 덧붙임: 4 개의 CPU 에서 테스트 되었고, MP 표준에 따르면 이론적으로 16 CPU 까지 지원할수 있습니다.

   리눅스 커널 2.2.x 이상에서 UltraSparc, SparcServer, Alpha 와 PowerPC 등을 지원합니다.

   Ralf B?hle로 부터:

   MIPS, m68k 와 ARM 은 SMP를 지원하지 않습니다. m68k 와 ARM은 아마 영원히 지원하지 않을것입니다.

   저는 MIPS-SMP 박스가 생기는 데로 SMP 지원을 위해 해킹을 해보려고 합니다.

3. 리눅스 SMP 커널은 어떻게 만드나요?

   많은 리눅스 배포본들이 SMP 커널 패키지를 포함하고 있지 않기 때문에 (역자주: 사실 요즘 배포본들은 대부분 포함하고 있지만,) 당신이 직접 만들어야 합니다. 만약 당신이 아직까지 커널 컴파일을 해본적이 없다면 이것은 좋은 이유가 될것입니다. 커널 컴파일에 대한 설명은 이 문서의 목적에 벗어나므로, 더 자세한 내용은 Linux Kernel Howto 를 참고하세요. (C. Polisher)

   커널 2.0 이상 (2.1.132을 제외한) 에서는 커널의 주 Makefile (/usr/src/linux/Makefile)에서 SMP=1 라인의 주석을 풀어주면 됩니다.

   커널 2.2.x 이상에서는 Processor type and features ---> [*] Symmetric multi-processing support "Symmetric multi-processing support"를 yes 로 해줍니다. (Michael Elizabeth Chastain).

   그리고

   Character devices ---> [*] Enhanced Real Time Clock Support

   위와 같이 "RTC support" 를 yes 로 해줍니다. (Robert G. Brown). RTC 지원은 우리가 알고 있는 문제인 SMP 시스템의 시간의 느려짐을 해결하지는 않을것입니다, 그러나 부팅시 시간을 읽을때의 정지현상을 예방해 줍니다. 또한 RTC 기능은 몇몇 오리지날 인텔 메인보드에서 두번째 CPU를 인식하는데 필요합니다 (Richard Jelinek).

   그리고

   x86 커널에서는 APM (advanced power management) 기능을 넣지 마십시요! APM 과 SMP 는 호환하지 않습니다. 그리고 당신의 시스템은 분명히(최소한 아마도 ;)) 부팅시에 문제를 일으킬 것입니다 (Jakob Oestergaard). 2.1.x 이상의 SMP 커널에서는 APM 기능은 꺼집니다. 기본적으로 APM 은 SMP 시스템에서 미정이며, 무슨일이든지 일어날 수 있습니다. (Alan Cox)

   그리고

   x86 커널은 "MTRR (Memory Type Range Register)" 기능을 커널에 넣습니다. 이것은 몇몇 버그가 있는 BIOS에서 두번째 프로세서의 캐쉬 메모리가 작동하지 않는것을 해결 해 줍니다.

   당신은 커널과 모든 관련 모듈들을 SMP 모드로 다시 컴파일 해야합니다. make modules 과 make modules_install 을 잊지 마십시요 (Alan Cox).

   만약 모듈 적재 오류가 생긴다면 당신은 아마 모듈들을 컴파일 하지 않았거나 재 인스톨 하지 않았을 것입니다. 또한, 몇몇 2.2.x 대의 커널에서 SMP 커널에서 일반커널로의 재 컴파일시 문제가 있다는 보고가 있었습니다. 이것을 해결하려면 .config 파일을 저장해(다른 곳에) 놓은 다음, make mrproper 한후, 백업해놓은 .config 파일을 복사한후 커널을 재컴파일 합니다. (Wade Hampton). 커널 컴파일후 lilo 실행을 잊지 마십시요.

   요약:

   make config # 또는 menuconfig 또는 xconfig make dep make clean make bzImage # 또는 원하는 것으로(make zlilo,...) # 커널 이미지를 복사한후(/boot/에) lilo를 실행 make modules make modules_install

4. 비 SMP 커널을 어떻게 만드나요?

   커널 2.0 대에서는 Makefile (/usr/src/linux/Makefile) 에서 SMP=1 라인을 주석 처리합니다.

   2.2 대에서는 커널 설정시 "Symmetric multi-processing support" 에 no 로 대답하면 됩니다 (Michael Elizabeth Chastain).

   당신은 커널과 관련 모듈 모두를 재 컴파일, 인스톨 해야합니다. make modules 와 make modules_install 그리고 lilo를 실행 시키는 것을 잊지 마십시요.

5. SMP 커널의 작동 여부는 어떻게 확인하나요?

   cat /proc/cpuinfo

   dual PentiumII 의 전형적인 결과:

   processor : 0 cpu : 686 model : 3 vendor_id : GenuineIntel [...] bogomips : 267.06 processor : 1 cpu : 686 model : 3 vendor_id : GenuineIntel [...] bogomips : 267.06

6. 세밀한 락킹과 멀티스레딩 상태로 전환되는 커널의 상태는?

   리눅스 2.2 커널은 시그널 처리와 인터럽트와 몇몇 I/O 의 세밀한 락(lock)처리가 되어있다. 나머지는 천천히 이식되고 있다. 모든 스케줄링은 SMP에 안전하다.

   2.3 (다음 버젼인 2.4) 커널은 아주 세밀한 락킹 기능을 가지고 있다. 2.3 커널에서 커다란 커널 락의 사용은 기본적으로 사라지고 대부분의 리눅스 커널의 하부 시스템들은 충분히 스레드화 된다: 네트워킹, VFS, VM, IO, block/page 캐쉬, 스케줄링, 인터럽트, 시그널 등등. (Ingo Molnar)

7. 리눅스 SMP 가 프로세서의 유사성을 지원하나요?

   일반적인 커널

   아니요 & 네. 프로세스들을 특정 CPU 위에서 실행하게 하는 길은 없습니다. 그러나 리눅스 스케쥴러는 각 과정들을 위해 프로세서 성향을 가집니다. 그것은 프로세스들을 특정 CPU들에 연결시키게 하는 경향이 있습니다.

   패치

   네. 관련 사이트 PSET - Processor Sets for the Linux kernel: "이 프로젝트의 목적은 pset의 상호 호환성과 기능을 만들어 줍니다. (SGI에 의해 정의된 - 부분적으로 IRIX 6.4 커널에서 삭제된). 이것은 사용자들이 특정 프로세서(들)의 위에서 프로세스들을 동작하도록 결정하는 것을 가능하게 합니다. 그리고 스레드들은 분리된 프로세서들, 타이밍, 안전 (root 만의 CPU?) 에서 사용될수 있습니다. 그리고 아마도 더 많은 것들도."

   이것은 syscall sysmp()에 중점을 둡니다. 이 기능은 어느 기능이 요청되는가에 따라 많은 매개 변수들이 있습니다. 기능들은 다음을 포함합니다.

   • 프로세스/스레드를 특정 CPU에 고정하는것

   • 몇가지 프로세스들을 실행하는 CPU의 능력을 한정하는것

   • 집중되는 실행에서 CPU를 한정 시키는것 (restricting a CPU from running at all)

   • 오로지 한개의 프로세스(부 프로세스들을 포함)를 실행하도록 하는것

   • CPU의 상태에 대한 정보를 얻는것

   • 바운드 되어 있을지도 모르는 프로세스들의 생성과 파괴 (creating/destroying sets of processors, to which processes may be bound)

8. SMP 버그는 어디에 보고해야 하나요?

   linux-smp@vger.rutgers.edu.

9. SMP의 성능은 어떤가요?

   만약 당신이 SMP 시스템의 성능을 측정하고 싶다면 Cameron MacKinnon에 의해 만들어진 http://www.phy.duke.edu/brahma/benchmarks.smp에서 몇가지 테스트를 해볼수 있습니다.

2.2. 사용자의 측면

1. 나에게 SMP가 정말 필요한가요?

   만약 당신이 그렇게 물어봐야 한다면 아마도 아닐것 입니다. :) 일반적으로, 멀티 프로세서 시스템은 한개의 프로세서를 가진 시스템에 비해 더 낳은 퍼포먼스를 보여줍니다. 그러나 분명히 파악해야 할것은 CPU 의 수이외에 많은 다른 요인들을 고려할 필요가 있습니다. 예를 들어, 주어진 시스템의 프로세서가 느린 디스크 드라이브 때문에 쉬고 있다면, 이 시스템은 "input/output bound"이며, 프로세서의 추가로 얻는 이익은 적을 것입니다. 만약 시스템이 많은 프로세스들을 동시에 실행하고 있다면 프로세서의 추가로 얻는 이득은 많아집니다. 복수의 프로세서들이 사용될때 SCSI 디스크 드라이브들은 매우 효과적일수 있습니다.(C. Polisher)

2. 두개의 300 MHz 프로세서와 한개의 600 MHz 프로세서는 같은 능력을 수행하는지?

   이것은 수행되는 어플리케이션에 따라 다릅니다. 그러나 대부분의 경우는 아닙니다. SMP 는 단일 프로세서에 비해 약간의 오버헤드를 추가합니다. (Wade Hampton). :)

3. 어떻게 하면 여러개의 CPU의 성능을 출력해 볼수 있나요?

   Samuel S. Chessman의 덕택으로 몇가지 유용한 유틸리티들이 다음에 있습니다:

   문자:

   http://www.cs.inf.ethz.ch/~rauch/procps.html

   근본적으로 이것은 procps v1.12.2 이다. 그리고 SMP를 위한 약간의 패치들.

   2.2.x 대를 위한 패치는 이곳에 (Gregory R. Warnes) http://queenbee.fhcrc.org/~warnes/procps

   그래픽:

   xosview-1.5.1 는 SMP 를 지원합니다. 그리고 2.1.85 이상의 커널에서 /proc/stat 에 cpuX 항목이 있는 경우.

   xosview 의 공식 사이트는: http://lore.ece.utexas.edu/~bgrayson/xosview.html

   Kumsup Lee 에 의한 2.2.x 커널 패치들이 이곳에 있습니다. http://www.ima.umn.edu/~klee/linux/xosview-1.6.1-5a1.tgz

   이외 여러가지 패치들이 http://www-isia.cma.fr/~forissie/smp_kernel_patch/에 있습니다.

   당신은 xosview 로 프로세스 스케쥴링을 정확하게 모니터링 할수는 없습니다. xosview 자체가 하나의 프로세스 이며, 스케쥴링에 영향을 주므로 (H. Peter Anvin).

4. 커널 컴파일시 1개의 이상의 프로세스를 실행 시키려면?

   다음과 같이 합니다:

   # make [modules|zImage|bzImages] MAKE="make -jX" X 는 CPU 숫자입니다. 주의 : 이것은 "make dep" 에서는 적용되지 않습니다.

   2.2 대 커널에서는 /usr/src/linux/Documentation/smp.txt 문서를 참고하세요.

   복수의 프로세서들을 사용하기 위한 충분한 메모리와 입출력 속도(하드 디스크등의) 가 아니라면 컴파일과정에 더 지연을 일으킬수 있습니다. make MAKE="make -j 2" -j 2 는 실제로 단일 프로세서에서도 효과를 볼수 있습니다. (Ralf B?hle).

5. 왜 time 명령어가 부정확하게 작동하는지? (Joel Marchand)

   2.x 대의 커널에서 time 명령어의 결과는 부정확합니다. 유저와 시스템의 합은 맞습니다만, 유저와 시스템 사이에 spreading (배치? 발생?)되는 시간은 정확하지 않습니다.

   더 자세하게: 부트 CPU 이외의 프로세서들에 의해 사용되는 시간들이 시스템의 시간과 같다고 생각되기 때문이다. 만일 당신이 프로그램의 시간을 잰다면, 사용자 시간과 시스템의 시간을 더한다면 그것은 거의 정확할 것이다. (시스템 시간을 계산하는 시간을 제외한) (Jakob ?tergaard).

   이 버그는 2.2 커널에서 수정되었습니다.

2.3. SMP 프로그래밍

Jakob ?tergaard 에 의해

SMP 리눅스를 위한 다중 스레드 프로그래밍에 대한 섹션입니다.

3.1. 왜 내 컴퓨터에서 작동하지 않나요?

1. Cyrix, AMD 등의 인텔외의 CPU에서 SMP 를 사용할수 있나요?

   짧은 대답: 아니요.

   긴 대답: 인텔은 APIC SMP안 에 대한 소유권을 주장 하고 있습니다. 그리고 위 회사들이 그 안을 사용하고 있지 않고 있습니다. (이것은 미래에 바뀔수 있겠지요). 사이릭스와 AMD는 소유권이 보호되지 않는 OpenPIC를 지원합니다만, 현재까지 그것을 사용하는 마더보드가 존재하지 않습니다.

2. 왜 오래된 내 Compaq 에서 작동하지 않나요?

   MP1.1/1.4 호환 모드로 맞추어 놓으세요.

   "Configure Hardware" -> "View / Edit details" -> "Advanced mode" (F7 일 겁니다.) "APIC mode" 설정에서 "full Table mode"로 합니다. 이것은 컴팩의 공식적인 권장사항 입니다.(Daniel Roesen)

   (Adrian Portelli)은 다음과 같이 했습니다 :

   1. 서버 부팅시 F10을 누르면 시스템 설정으로 들어갑니다.

   2. 엔터를 누르고 스플레쉬 화면을 지나갑니다.

   3. 재빨리 CTRL+A 를 누릅니다.

   4. "Advanced Mode" 설정 메세지가 나타날 것입니다.

   5. "Configure Hardware" -> "View / Edit details" 를 선택하고,

   6. 설정 화면이 나타나면

   7. "APIC Mode" 까지 스크롤 한다음 "Fully Mapped"를 선택합니다.

   8. 저장하고 리부팅합니다.

3. 왜 ALR에서 작동하지 않나요?

   Robert Hyatt로부터: ALR Revolution quad-6 는 매우 안전해 보인다. 몇몇 오래된 revolution quad (P6 프로세서가 없는)는 불확실...

4. 왜 SMP 가 느리죠? 또는 왜 한개의 CPU가 다른 CPU에 비해 매우 낮은 보고밉스 값을 나타내지요?

   Alan Cox 로 부터: 만약 프로세서들 중 하나의 보고밉스 값이 매우 낮다면, 캐쉬가 작동하지 않는것 입니다. 당신의 마더보드는 아마도 버그가 있는 BIOS를 사용하고 있을것입니다. 패치(BIOS 업그레이드?)를 하던지 돌려보내든지, 새로 사던지 하세요.

   2.0 커널 (> 2.0.36) 에서 MTRR 패치는 이 문제를 해결해 줄것입니다. (커널 설정에서 "Handle buggy SMP BIOSes with bad MTRR setup" 를 선택하세요).

   마지막 버젼의 2.2 대 커널들은 버그가 있는 SMP BIOS 문제를 알아서 처리할것 이라고 생각합니다.

5. IBM 머쉰에서 문제들이 있다고 들었습니다.

   몇몇 IBM 의 EBDA 에서 MP1.4 bios 블럭을 가집니다. 이것은 허락되지만 2.2 커널 이하에서는 지원되지 않습니다.

   오래된 486SLC IBM SMP 박스에서 Linux/SMP 는 하드웨어 FPU 가 필요합니다.

6. 인텔 MP 1.4가 1.1 규정에 비해 이점이 있나요?

   아뇨 (Alan 에 의하면 :) ), 1.4 는 stricker specs of 1.1 일 뿐이다.

7. SMP 에서 왜 시계가 그렇게 빨리 가지요?

   2.0 대의 커널에서 알려진 문제이다, 2.2 대의 커널로 업그레이드를 고려해라.

   Jakob Oestergaard 로 부터: 또는, xntpd의 실행을 고려하세요. 이것은 당신의 시간을 정확하게 맞춰 줄겁니다. (커널에서의 RTC 지원도 이 현상을 막아준다라고 저는 생각합니다. 저의 경우 이것은 해당되었구요. 그러나 확실하지 않으므로 이것은 그저 행운일지도 모르지요.)

   이것을 예방할 수정이 2.2.x 대의 커널에 있었습니다.

8. 왜 내 프로세서들의 번호가 0 과 1이 아닌 0 과 2 로 되지요?

   CPU 번호는 마더보드 제조업체들에 의해 할당되는 것이며, 이것은 아무 의미도 가지지 않습니다. 무시하세요.

9. 내 quad-Xeon 시스템이 부팅시 정지됩니다.

   (Doug Ledford) LILO 를 LARGE_EBDA 지원하게 재컴파일 하십시요. 그리고 커널 빌드시 항상 make bzImage 로 하십시요. 이것은 인텔 다중 지온 보드의 SMP 부팅시 정지 를 막아줍니다. 그러나 이것은 LILO 에서 root= 옵션이 더이상 작동 하지 않습니다. 그러므로 확실히 rdev 로 당신의 커널이 정확한 루트 파티션을 사용하도록 해야 합니다.

   (Robert M. Hyatt) 3개의 CPU를 사용한다면, 네번째 소켓에 터미네이터가 있나요?

10. 부팅시 IOAPIC 시그날과 함께 정지 됩니다.

    부팅 옵션에 "noapic" 를 넣거나(John Aldrich) 그리고(또는) "reboot=bios" 를 사용합니다. (Terry Shull).

11. 내 시스템이 NFS에 많은 부하가 걸렸을때 정지 됩니다.

    커널 버젼 2.2.x 이상과 knfsd 패치를 사용 해보십시요. 이것은 현재 조사중입니다. (Wade Hampton)

12. 내 시스템이 oops 메시지없이 정지 됩니다.

    만약 당신이 커널 2.2.11 또는 2.2.12를 사용하고 있다면 마지막 버젼의 커널을 사용하십시요. 2.2.13에서 몇가지 SMP 관련 패치가 있었습니다. 몇몇 사람들에게서 이 버젼(2.2.11 과 2.2.12)가 SMP 모드에서 안정적이지 않다는 보고가 있었습니다 (NFS 문제들도). 시리얼 콘솔을 사용해 커널의 oops 메세지를 캡춰해 볼수 있습니다. (Wade Hampton)

    계속 문제가 있다면(그리고, 다른 사항들 조차 도움이 되지 않았다면), 당신은 2.3 대의 커널을 시도해 볼수 있습니다. 이 버젼의 커널들은 더 많고, 강력한 SMP/APIC 코드를 가지고 있습니다. 그리고 automatic hard-lockup-prevention code 는 그저 조용히 멎어 (시스템이) 버리는 것이 아니라 쓸모있는 oopses 메세지를 남길것입니다. (Ingo Molnar)

    (Osamu Aoki) 가 : 당신은 또란 BIOS 와 관련된 모든 전력 절약 모드를 불가능하게 하게 해야합니다. 다음은 올바른 설정의 예입니다. (듀알 Celeron 466 / Abit BP6):

    POWER MANAGEMENT SETUP. ACPI: Disabled POWER MANAGEMENT: Disabled PM CONTROL by APM: No

    만약 절전 모드가 켜져 있다면, 무작위적인 시스템 다운이 일어날수 있습니다.

13. 시스템 정지 디버깅

    이절은 Wade Hampton에 의해 씌여졌음.

    시스템 정지 디버깅의 좋은 수단은 Andrea Arcangeli에 의한 ikd 패치를 사용하는 것입니다. ftp://ftp.suse.com/pub/people/andrea/kernel-patches

    몇개의 디버깅 옵션이 있는데, soft lockup 옵션은 사용하지 마세요. 새로운 SMP 머쉰들은 NMI oopser상에서 커널 디버깅 옵션을 사용합니다. NMI oopser 의 작동 확인은 /cat /proc/interrupts 의 결과에 NMI 가 있는지 보면 됩니다. 이제 시스템이 정지되면 당신은 oops 메세지를 얻을수 있을것입니다.

    또한, %eip 옵션을 시험해 보아도 좋습니다. 이것은 커널이 커널 함수가 불려질때마다, 콘솔상으로 %eip 주소를 출력해 줍니다. 시스템이 정지될때, 다음 두번째 칼럼에 의한 첫번째 칼럼을 적어둔후, System.map 파일에서 그 주소를 찾아 봅니다. 이것은 콘솔모드에서만 할수 있습니다.

    또한 시리얼 콘솔은 커널 정지를 디버깅하는데 대단히 편리합니다. (단지 SMP 커널만이 아닌.)

14. 로그의 "APIC error interrupt on CPU#n, should never happen" 메시지

    다음과 같은 메세지는

    APIC error interrupt on CPU#0, should never happen. ... APIC ESR0: 00000002 ... APIC ESR1: 00000000

    잘못된 체크섬 에러를 가르킵니다. 이것은 리눅스(하드웨어 체크섬 부분의 APIC 메세지)에 기인할수 없습니다. 이것은 추가(주변 기기?) 하드웨어에 의한 것일지도 모릅니다. 시스템의 불안정함이 보일때까지는 이것은 문제가 되지 않습니다. - APIC 메세지는 배달될때 까지 재시도 됩니다. (Ingo Molnar)

3.2. 충돌의 가능한 원인들

이번 장에서는 SMP 머쉰의 비정상적인 작동의 원인들을 찾을수 있을것이다. (Jakob tergaard)

• 냉각

  Ralf Bhle 로부터 : [이 경우 팬들의 크기에 관련이 있었다] 공기의 흐름이 중요합니다. 너무 작은 케이스는 문제를 일으킬수 있습니다. 반대로 쓸데없이 큰 케이스도 문제의 소지가 있습니다. 일반적인 타워케이스가 데스크탑들 보다 약간 냉각효율이 좋다고 봅니다. 요컨대, 좋은 케이스는 공기역학적으로 설계되어 있겠지요.

  당연히 여러분은 전자상가에서 다른 팬을 추가할수 있습니다. 또한 여러분은 메인보드에 장착되어 있는 lm 센서로 CPU와 메인보드의 온도,전압등을 모니터링 할수 있습니다. (http://www.netroedge.com/~lm78) 이것은 과열문제를 도와줄수 있습니다. (Wade Hampton)

• 나쁜 메모리

  싸구려 램을 사지 마세요. 그리고 다른 램 모듈들을 혼합해서 사용하지 마십시요.

  특히 Tyan 마더보드들은 램 속도와 관련하여 문제가 있습니다. (다음장의 Tyan 마더보드들에 대한 해결책을 보세요.)

  CPU가 8ns 램을 사용해야 하는 경우, 10ns의 PC100램을 사용한 마더보드들에서 버그 보고가 있었습니다. (Wade Hampton)

• 다른 스텝핑을 가진 프로세서들의 나쁜 조합

  /proc/cpuinfo 을 확인해서 프로세서들이 같은 스테핑(stepping)을 가지고 있는지 확인해 봅니다.

• 만약 당신의 시스템이 불안정 하다면 오버클럭을 하지 마세요!

  만약 안정적이라 하더라도, 오버클럭은 하지 않는게 좋습니다.

  Ralf Bhle로부터 : 오버클럭킹은 미묘한 문제들을 일으킵니다. 좋은 예로, 나의 오버클럭한 오래된 기계들중에 640x400 의 프랙탈 픽셀들을 그려내는데 오류를 일으킵니다. 이 문제들은 도구를 사용하여 비교하면 나타납니다. 그러므로, 오버 클럭킹은 절대 (never, nuncas, jamais, niemals) 하지 마세요.

• 2.0.x 대의 커널과 fast ethernet (Robert G. Brown)

  2.0.x 커널에서 놓은 성능의 빠른 이더넷 시스템이 중요한(그리고 알려진) 문제를 넥트웍 인터럽트 핸들에서 가지고 있습니다.

  해결책은 마지막 개발 버젼의 100BT 드라이버를 다음에서 구하는 것입니다. CESDIS 리눅스 이더넷 드라이버 사이트 (SMPCHECK을 정의한).

• 440FX 칩셋에서의 버그 (Emil Briggs)

  만약 당신의 시스템의 마더보드가 440FX 칩셋을 사용하며, 시스템이 정지되는 문제가 있다면 칩셋의 문서화된 정오표에 의한 것일수 있습니다.

  참조 : 인텔 440FX PCIset 82441FX (PMC) 와 82442FX (DBX) 규격의 업데이트. pg. 13

  http://www.intel.com/design/pcisets/specupdt/297654.htm

  이 문제는 BIOS 이 업그레이드 (또는 커널 패치)로 해결할수 있습니다. 그리고 실제로 David Wragg 는 Richard Gooch 의 MTRR 패치를 포함하는 커널 패치를 썼습니다. 더 많은 정보는 다음을 참고:

  http://nemo.physics.ncsu.edu/~briggs/vfix.html

• 리눅스 SMP로 부팅하기전에 emm386.exe를 실행시키지 마세요.

  Mark Duguid 로 부터, 특히나 W6LI 마더보드에서는. ;)

• 만약 당신의 시스템이 리부팅후 멎어 버린다면, 두가지 원인이 있을수 있습니다. (BIOS 와 메모리와 관련된) (Jakob ?tergaard)

  • 만약 BIOS 의 설정중 "memory hole at 16M" 또는 "OS/2 memory > 64MB" 을 disable 로 하십시요, 리눅스는 이 옵션들에 반응하지 않습니다.

  • 만약 당신이 64MB 이상의 메모리를 가지고 있다면, 그리고 당신이 lilo 설정에 수동으로 메모리양을 적어 주었다면, 그 설정을 실제의 메모리양에서 1MB 적게 적어 주세요. 예를 들어 128MB 를 가지고 있다면, append="mem=127M"

• IRQ 와 관련된 문제들중 알아야 할것

  몇몇 카드들이 인식되지 않거나, IRQ 충돌 현상이 있다면 카드들을 서로 다른 슬롯으로 옮겨 보거나, IRQ 를 바꿔봅니다.

  hASCII 에 의해 : 리로 설정 파일에서 "append="hisax=9,2,3"" (ISDN +Hisax 지원을 위한) 을 지웁니다. (커널 2.1.xx). 2.0.xx 에서는 문제 없음.

  BIOS 설정에서 "MP 1.4 mode" 또는 "route PCI interrupts through IOAPIC", 또는 "OS Type" 와 같은 설정들을 DOS 또는 Novell 로 설정하지 마세요. (Ingo Molnar).

• 플로피와 사운드 카드가 동시에 사용할때

  만약 플로피를 사용하려 할때(예를 들어 사운드를 플레이 하면서) 시스템 정지가 일어 난다면, drivers/pci/quirks.c 파일을 다음과 같이 고칩니다. /int isa_dma_bridge_buggy = 1; 이 문제는 내 Dell WS400 dual PII/300, 2.2.x, SMP에서 일어 났습니다. (Wade Hampton).

3.3. 마더보드 특정 정보

주의할점: 몇몇 많은 특정 정보는 다음 사이트에서 찾을 수 있다. 리눅스 SMP를 동작시킬 수 있는 마더보드

3.4. 저가의 SMP 리눅스 박스(듀얼 셀러론 박스)

(St?hane ?olivet)

현재로 살만한 가장 저가의 SMP 리눅스 박스는 듀얼 셀러론 시스템이다. 그러한 시스템은 인텔에 따르면 공식적으로는 가능하지 않다고한다. 2세대 셀러론 (128kb L2 캐시)를 고려하는게 좋다.

4.1. 어떤 스팍 머신이 지원되나?

다음의 사이트UltraLinux를 살펴보면 (오직 SMP 시스템에 관해서):

• UltraSPARC PCI 기반의 워크스테이션들: Ultra60, Ultra450

• UltraSPARC SBUS 기반의 서버들: Enterprise 1, 2, 150

• UltraSPARC SBUS 기반의 큰 서버들: Enterprise 3000, 4000, 5000, 6000, 10000

• UltraSPARC PCI 기반의 서버들: Enterprise 250, 450

• SPARC sun4m SMP 머신들 (Anton Blanchard)

UltraLinux는 14개의 CPU 머신에서도 작동한다. (참고 사이트 dmesg 결과입니다).

4.2. 스팍 SMP 지원과 관련된 문제

(David Miller) 특별한 걱정은 없습니다.

유일하게 알려진 문제는 고치려 하지 않았지만 만일 32비트 시스템 (즉 ultrasparc이 아니라는 의미) SMP 커널을 형성시키고자 하면 커널은 sun4c 시스템에서 작동하지 않는다.

4.3. 최신 커널(2.2)이 갖고 있는 SMP의 특정한 제한사항

(David Miller) include/linux/tasks.h 에 버그가 있는데 NR_CPUS를 지원하는 하드웨어에 대한 상한 선으로 UltraSparc에서 64로 하는 것이 좋다. :-)

5.1. 어떠한 PPC 머신들이 지원되나?

• PowerSurge 보드들 (UMAX s900을 포함해서)

• PowerMac

• Motorola MTX: 지원은 아직 개발중이다. 패치들은 아직 커널에 포함되어 있지 않다. (Troy Benjegerdes)

(Cort Dougan) PPC RS/6000 시스템들도 아직 지원이되지 않는다.

5.2. PPC SMP 지원에 관련된 특정 문제들

문제는 없다. 대개 SMP 컴파일에는. 대개는 UP나 SMP 둘중에 하나에 모듈이 특정화되어있다. 커널을 재컴파일하라. (Paul Mackerras)

6.1. 어떠한 알파머신들이 지원되나?

(Geerten Kuiper) SMP는 대부분의 AXP 서버에서는 잘 작동한다.

(Jay A Estabrook) SMP는 대부분의 컴팩 제품에는 동작하는 것 같다. 두개 이상의 CPU를 갖는 박스는 다음을 포함한다:

• AS2000/2100 (SABLE)

• AS4000/4100 (RAWHIDE)

• DS20 (DP264)

포함하지 않는 것은:

• AS2100A (LYNX)

• TurboLaser bigboys (8200/8400)

6.2. 알파 SMP 지원에 관련된 특정문제들

없습니다.

7.1. 다양한 것들

• 리눅스를 이용한 병렬처리

• 리눅스 병렬처리 HOWTO

• (오래되었지만) 리눅스 SMP 홈페이지

• 리눅스-smp 메일링 리스트

  구독하려면, subscribe linux-smp라는 내용으로 majordomo@vger.rutgers.edu의 주소로 보내라.

  unsubscribe하고 싶지 않다면, unsubscribe linux-smp라는 내용으로 majordomo@vger.rutgers.edu으로 메일을 보내면 된다.

  리눅스 SMP 모음

  progressive-comp.com의 리눅스 SMP모음

• Xavier Leroy가 만든 pthread 라이브러리

• 리눅스 SMP가 작동하는 것으로 알려진 마더보드

• procps

• 커널 2.2.x를 위한 procps 패치

• xosview

• 커널 2.2.x를 위한 xosview

• 리눅스의 SMP 성능

• CESDIS 리눅스 이더넷 디바이스 드라이버 사이트

• 듀얼 셀러론 시스템

7.2. 멀티스레드 프로그램과 라이브러리

• 리눅스 스레드 FAQ

• 리눅스에서 멀티스레드 프로그램

• 인텔 펜티엄 프로에 최적화된 BLAS와 FFT Blas 뉴스

• Mesa 라이브러리

• GIMP를 위한 병렬 플러그인

7.3. 특정 SMP 패치들

• Forissier 커널 패치들

• 440FX 칩셋의 버그를 위한 패치

• MTRR 패치

• PSET - 리눅스 커널을 위한 프로세서 세트

• Ingo Molnar SMP 패치

7.4. 586/686 머신을 위한 병렬/최적화 컴파일러 (Sumit Roy)

• 펜티엄 컴파일러 그룹 pgcc의 창시자들

• Absoft 포트란 90과 77 컴파일러

• Portland Group 회사는 supports the OpenMP라는 리눅스에서 포트란 코드를 병렬화 시키는 표준을 지원한다.

• Pacific-Sierra 연구소는 자유롭게 사용할 수 있는 F90 컴파일러를 SMP 리눅스를 위해 개발했다.

• Applied Parallel Research는 현재 윈도우즈 NT를 위해 병렬 컴파일러를 개발한다.

• KAI는 OpenMPI 실행이 가능한 리눅스를 위해 C++-컴파일러를 갖고 있다. 이를 Guide_OpenMP라 한다. 더 많은 정보는 http://www.kai.com/parallel/kappro/guide에서 찾을 수 있다. (Gero Wedemann)