9. 도서관/__사. Network

L2 Cache 이벤트와 프로세서 오프라이닝

행복 금융 2008. 11. 16.

 
 
 
 

L2 Cache 오류 검사 및 수정(ECC) 이벤트가 로깅되면 이벤트가 프로세서 오프라이닝 (Processor Offlining) 기준을 충족시키는지 여부를 확인하기 위해 이벤트 세부 항목들에 대한 검사가 이루어진다. 한편, 이러한 변화는 UltraSPARC?III 기반의 시스템에서만 찾아볼 수 있는데, 이는 구현 자체가 프로세서의 특정 커널 코드로 제한되기 때문이다. UltraSPARC?IIIi를 제외한 모든 UltraSPARC?III 기반 시스템들의 경우 이 기능은 ‘사용’ 상태로 기본 설정되어 있으며, 이 기본 설정값은 /etc/system 파일의 엔트리를 통해서 변경될 수 있다. ECC 이벤트는 크게 다음과 같이 3 가지의 종류로 구분할 수 있다.

● 단일 비트의 수정 가능한 L2 Cache 이벤트
● ME 비트 세트가 사용되는 UCC 이벤트
● 복구 불가능한 L2 Cache 이벤트


카테고리 A > 단일 비트의 수정 가능한 L2 Cache 이벤트
이 카테고리에는 다음과 같이 4 가지 L2 Cache 수정 가능 이벤트가 있다.

● UCC - 블록 로드 이외의 명령어 인출(instruction fetch) 또는 데이터 액세스와 관련한 소프트웨어-수정 가능 L2 Cache ECC 오류
● CPC - copyout과 관련한 하드웨어-수정 L2 Cache ECC 오류(snoop 명령 요청)
● WDC - writeback과 관련한 하드웨어-수정 L2 Cache ECC 오류
● EDC - store merge 또는 블록 로드와 관련한 하드웨어-수정 L2 Cache ECC 오류
UltraSPARC? III Cu 시스템에서 소프트웨어 또는 하드웨어 프리페치(prefetch) 액세스와 관련한 하드웨어-수정 L2 Cache ECC 오류는 EDC를 생성시킨다.

이 각 이벤트마다 오류가 수정되고, 트랩을 처리하는 스레드를 재시작할 수 있게 된다. 하지만, 반복되는 이벤트는 CPU 및 관련 L2 Cache를 교체대상 후보로 지정한다. 이벤트 타임스탬프(timestamp)는 SERD(Soft Error Rate Discrimination) 알고리즘으로 전달되어 24시간 동안 동일한 프로세서에서 서로 다른 3가지의 이벤트가 발생하는 시점을 탐지하게 된다. 3번째 이벤트가 탐지되면 프로세서는 오프라이닝 후보로 지정된다.


카테고리 B> ME 비트 세트가 사용되는 UCC 이벤트

ME(multiple error) 비트 세트의 특수한 UCC 이벤트 조합은 위에서 언급한 것처럼 3가지의 서로 다른 UCC 이벤트가 아주 빈번하게 연이어 발생하는 것처럼 취급된다. 이 경우 SERD 알고리즘은 short-circuited되고 프로세서는 즉시 오프라이닝 대상이 된다. ME가 다른 이벤트가 아닌 UCC에 의해서만 발생하게 된 결과인지 여부를 확인하기 위한 정밀한 검사가 이루어진다.


카테고리 C> 복구 불가능한 L2 Cache 이벤트

이 카테고리에는 다음과 같은 4 가지의 L2 Cache 복구 불능 이벤트가 있다.

● UCU - 블록 로드 이외의 명령어 인출(instruction fetch) 또는 데이터 액세스와 관련한 복구 불능 L2 Cache ECC 오류
● CPU - copyout과 관련한 복구 불능 L2 Cache ECC 오류(snoop 명령 요청)
● WDU -writeback과 관련한 복구 불능 L2 Cache ECC 오류(victimization, TransDog)
● EDU - 또는 블록 로드와 관련한 복구 불능 L2 Cache ECC 오류
UltraSPARC? III Cu 시스템에서 소프트웨어 또는 하드웨어 프리페치(prefetch) 액세스와 관련한 복구 불능 L2 Cache ECC 오류 또한 EDU를 생성시킨다.

각 이벤트에 대하여 트랩을 처리하는 스레드의 재시작이 가능하지만 프로세서는 곧바로 오프라이닝의 대상이 된다. 한편, CPU 종류에 따라 프로세서 오프라이닝으로 이어지지 않을 수도 있는 몇 가지 특수한 징후들이 있다. 이때 오류가 발견된 CPU라고 해서 반드시 이상이 있는 CPU라고 볼 수는 없다. UltraSPARC? IIIi 시스템의 경우 단 한 가지의 특수한 징후가 있는데 그것은 바로 0x3이다. 다른 UltraSPARC? III 시스템 기반 시스템에서는 0x3, 0x71 및 0x11c과 같은 특수한 징후들이 발생한다.

108528-24 이전의 Solaris 8 Kernel 업데이트 패치와 Solaris 9 Kernel 업데이트 패치 112233-08, 그리고 이전 패치의 경우에는 WDU와 EDU가 프로세서 오프라이닝 대상으로 취급되지 않는다.따라서 특정 커널 업데이트 릴리즈에서의 WDU 및 EDU 이벤트에 대해서는 프로세서 오프라이닝이 수행되지 않는다. 또한, 이 커널 업데이트에서는 메모리 UE 및 DUE 오류로 인해 CPU가 정상적으로 오프라이닝되지 않을 가능성이 있다. 이런 상황이 발생하게 되면 /etc/system 파일의 tunables를 통해 프로세서 오프라이닝 카테고리 C 클래스를 비활성화시키도록 한다. Solaris 8의 경우에는 Solaris 8 커널 업데이트 패치 108528-24로 업그레이드를 실시한다.

 

프로세서가 오프라이닝 대상으로 정해졌으면 범용 OS 인터페이스 cpu_offline()를 통해 프로세서 오프라이닝이 시도된다. 이는 효과 면에서 psradm 명령을 실행하는 경우와 비슷하며, 작업 성공 여부 또는 그 시점에 따라 동일한 제한 사항의 영향을 받는다. 오류 로깅이 오프라이닝 후보 프로세서 상에서 실행되면 가능한 다른 프로세서가 오프라이닝을 시도하려는 현상이 발생한다.

이 시도가 실패할 경우 특정 시간이 경과한 후 오프라이닝 재시도는 반복해서 이루어진다. 예를 들어 다른 프로세서로 곧바로 이동할 수 없는 스레드가 실행중이거나 이 프로세서가 프로세서 세트 중 유일한 CPU일 경우에 오프라이닝 시도는 실패하게 된다. 다른 프로세서로의 전환이 불가능한 이 프로세서에 인터럽트가 할당되면 프로세서는 여전히 인터럽트 핸들러 코드를 실행하고, 결국 다음 이벤트의 영향을 받게 될 수도 있다. 오프라이닝 시도 횟수가 지정된 한도를 초과할 경우 알고리즘은 시도를 멈추게 되고 프로세서는 오프라인되지 않는다. 하지만 이 기능은 계속 살아 있게 되는데, 왜냐하면 나중에 추가로 L2 Cache ECC 이벤트가 발생할 경우 다시 오프라이닝 시도를 해야 하기 때문이다. 최대 시도 횟수와 그 간격은 tunables이고, 이는 /etc/system 파일에서 설정할 수 있다. 가령 psradm을 사용하여 시스템 관리자가 오프라인된 프로세서를 온라인으로 되돌려야 할 경우 이 프로세서는 시스템의 다른 프로세서들처럼 다시 이 알고리즘의 영향을 받게 된다.

이 알고리즘을 통해 프로세서가 오프라인되면, 다음 POST/reboot의 구성에서 프로세서 제거를 허용하기 위한 Processor indictment 메시지가 Sun Fire 클래스 시스템의 시스템 컨트롤러에 전달된다. 한편, 이 기능과 다른 여러 기능을 지원하기 위해 Sun Fire 6800/4810/ 4800/3800 시스템용 펌웨어 5.15.3이 패치 112884-04을 통해 제공된 바 있다. 더 자세한 내용은 ‘Sun Fire(tm) 6800/4810/4800/ 3800 System Auto Diagnosis and Recovery Enhancements’ 란 제목의 Sun Blueprints Online 기사를 참고하기 바란다.

 

프로세서 오프라이닝에는 DR(dynamic reconfiguration, 동적 재구성)이 사용되지 않는다. 단일 프로세서, 심지어는 모든 프로세서가 보드 상에서 오프라인될 경우 시스템 보드 전체에 대해 자동 DR은 실행되지 않는다. 시스템 관리자가 해당 도메인을 벗어나서 오프라인 프로세서 상태를 유지하고 있는 시스템 보드 상의 DR을 수동으로 실행할 경우 프로세서는 POST 프로세스가 제대로 동작해야만 다시 작동할 수 있게 된다.

 

CoD(Capacity on Demand)와 프로세서 오프라이닝 간에는 상호 작용이 일어나지 않는다. 한 마디로 상호 작용은 시스템 관리자가 psradm 명령을 사용하여 수동으로 프로세서를 오프라인시켜야 하는 상황에서 볼 수 있는 것과 동일한 상태로 유지된다.

> 메시징의 예
오프라이닝 알고리즘의 경우 다음과 같은 세 가지의 시나리오가 발생할 수 있다.

● 프로세서를 성공적으로 오프라인하는 경우
● 초기에 실패하고 재시도하는 경우
● 몇 번의 실패 후에 결국 포기하게 되는 경우(앞서 언급한 ‘프로세서 오프라이닝 방법’ 참조)

각각의 시나리오에 대해 별도의 메시지가 콘솔과 시스템 메시지 로그 파일에 출력되며, 모든 메시지에는 오프라인 시도 대상 프로세서와 일반 카테고리를 확인하는 내용이 표시된다. 이 정보는 결국 오프라인 하드웨어 교체를 요청받은 서비스 요원이 유용하게 활용할 수 있다.

위에 정의된 3개의 각 카테고리(A, B, C)와 관련하여 오프라인 알고리즘이 내보낸 최종 메시지의 예가 아래에 나와 있다.


> 카테고리 A 메시지

카테고리 A 메시지의 예가 아래에 나와 있다.

Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 962502
kern.info] NOTICE: [AFT0] WDC Event detected by CPU64 at TL=0,
errID 0x000000e3.2774aaf0
Oct 23 11:37:05 sf15k-domc AFSR 0x00000040<WDC>.000001f0 AFAR
0x000000a1.f06b4000
Oct 23 11:37:05 sf15k-domc Fault_PC 0x10152880 Esynd 0x01f0
SB2/P0/E0 J4400
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 189302
kern.info] [AFT0] errID 0x000000e3.2774aaf0 Data Bit 111 was in
error and corrected
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 860712
kern.info] [AFT2] errID 0x000000e3.2774aaf0 E$tag
PA=0x000000a0.00eb4000 does not match AFAR=0x000000a1.f06b4000
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 260100
kern.info] [AFT2] errID 0x000000e3.2774aaf0
PA=0x000000a0.00eb4000
Oct 23 11:37:05 sf15k-domc E$tag 0x00000140.01000001 E$state_0
Shared
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 895151
kern.info] [AFT2] E$Data (0x00) 0x00000000.00000000
0x00000000.00000000 ECC 0x000
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 895151
kern.info] [AFT2] E$Data (0x10) 0x00000000.00000000
0x00000000.00000000 ECC 0x000
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 895151
kern.info] [AFT2] E$Data (0x20) 0x00000000.00000000
0x00000000.00000000 ECC 0x000
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 895151
kern.info] [AFT2] E$Data (0x30) 0x00000000.00000000
0x00000000.00000000 ECC 0x000
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 929717
kern.info] [AFT2] D$ data not available
Oct 23 11:37:05 sf15k-domc SUNW,UltraSPARC-III: [ID 335345
kern.info] [AFT2] I$ data not available.Processor Offlining for L2 Cache Events 7


두 번째 WDC 이벤트 발생 시 생성되는 메시지는 첫 번째 WDC 이벤트의 경우와 비슷한 형식으로 로깅된다.

Oct 23 11:38:05 sf15k-domc SUNW,UltraSPARC-III: [ID 137784
kern.info] NOTICE: [AFT0] WDC Event detected by CPU64 at TL=0,
errID 0x000000f1.217a63c1

세 번째 WDC 이벤트의 경우에는 첫 번째와 두 번째 이벤트에서처럼 정상적인 메시지가 표시되었으며, 다음과 같은 추가 메시지도 포함되어 있다.

Oct 23 11:39:37 sf15k-domc SUNW,UltraSPARC-III: [ID 709559
kern.info] NOTICE: [AFT0] WDC Event detected by CPU64 at TL=0,
errID 0x00000106.a62214d3

Oct 23 11:39:38 sf15k-domc SUNW,UltraSPARC-III: [ID 732650
kern.notice] NOTICE: [AFT1] Failed to offline CPU64 due to more
than 2 xxC Events in 24:00:00 (hh:mm:ss), will try again


이 경우 CPU는 곧바로 오프라인될 수 없으며, 이후에 시스템은 몇 초 정도 더 재시도를 한다.

Oct 23 11:40:08 sf15k-domc SUNW,UltraSPARC-III: [ID 915404
kern.notice] NOTICE: [AFT1] CPU64 offlined due to more than 2 xxC
Events in 24:00:00 (hh:mm:ss)

이제 CPU가 성공적으로 오프라인되었음을 알 수 있다.

 
 

댓글

💲 추천 글