티스토리 뷰

Study/OS

[OS] Mint64OS 31절 Symmetric I/O mode

생각많은 소심남 2013. 2. 12. 20:05

지난 포스트까지 멀티코어를 활성화시키는 예제를 따라했다. 그런데 사실 활성화만 시킨다면 의미가 없다. 프로세서가 인터럽트를 수행한다는 말은 직접적으로 인터럽트를 처리하는 것이 아니라 인터럽트가 다른 부분에서 처리하는 동안 context를 저장하고 Interrupt code에 따른 부분을 수행하고 다시 복원하는 작업을 수행하는 것이다. 그런데 이 저장/복원, 수행 과정은 프로세서에 일정 자원을 소모하는 것이기에 하나의 부하로 작용한다. 멀티코어 지원 OS라면 이런 작업을 여러 프로세서가 나눠서 효율적으로 처리할 수 있어야 하면, 보통 이런 것을 Interrupt Load Balancing이라고 한다. 이제는 활성화는 단계가 아닌 써먹을 단계가 되어야 하는 것이다.

 지나간 내용을 다시 돌아보면 싱글코어에서는 프로세서와 PIC가 직접적으로 연결되어 있어서 인터럽트를 전달했었는데 멀티코어를 위해서는 기존의 PIC를 감당하지 못하기 때문에 따로 Advanced PIC라는 개념을 도입했었고, 이중에서 I/O APIC와 Local APIC가 중추적인 역할을 한다. 이 APIC들을 통해서 인터럽트를 분산처리하는 것을 Symmetric I/O mode라고 한다. 참고로 인터럽트가 발생시에는 기존의 PIC는 비활성화된 상태에서 Local과 I/O APIC에 전달된다. 보통 Local APIC는 프로세서들과 같이 뭉쳐있기 때문에 인터럽트 발생시 일차적으로 I/O APIC으로 들어간 후에 분배되는 형태를 취한다. 원래의 인터럽트를 코어별로 나누는 개념을 여기서는 Redirection이라는 이름으로 표현했다. 당연히 APIC에서 나오는 경로를 지정하는 부분이 필요할 것이며, 인터럽트에 따라 수행할 것을 결정하게 해주는 테이블도 필요하다. 그리고 기존의 PIC에서 했던 것처럼 IRQ가 인터럽트를 받는 경로이기 때문에 이를 APIC와 어떻게 연결할 건지도 결정해줘야 할 것이다.


지난 포스트에서 말했던 것처럼 멀티코어에서 부팅역할을 수행하는 Bootstrap Processor가 있고, 일을 처리하는 Application Processor가 있다고 했다. 우선은 BSP가 활성화된 상태에서 symmetric I/O mode로 전환한 모습이다.



참고로 레이블을 설정하는 과정에서 인터럽트가 발생하면 문제가 발생할 수 있기 때문에 테이블 설정이전에 미리 PIC와 연결된 모든 IRQ를 masking 하는 과정이 필요하다. 물론 이 과정에서는 CPU도 인터럽트 플래그를 쓸 필요가 없어지는 거이다. 위와 같이 ap로 전환된 상태에서도 특별히 인터럽트가 발생하지 않고 명령어를 잘 수행한다. 하지만 문제는 재 부팅한 후이다.


이전 과정에서 BSP에서 AP로 전환된 후이기 때문에 부팅이 되기 전에는 작업을 할 수 없다. 그래서 위와 같이 PIC컨트롤러와 Interrupt가 초기화되면서 예외처리가 발생하는 것이다. 이미지 상에서는 PASS라고 나와있는데 사실은 실패에 대한 예외 구문이 없기에 위와 같이 나온다. 물론 Reset하면 다시 원상태로 복구된다.


비로소 64bit 멀티코어 OS 원리와 구조 1권책을 마쳤다. 물론 이 책안에 있는 내용을 모두 안다고는 말 못하겠지만 정말로 운영체제의 내부구조에 대해서 다시 돌아볼 수 있었던 계기였던 것 같다. 물론 부족함으로 더 많이 느끼고, 시간이 된다면 다시한번 볼 생각이다.

댓글