안녕하세요. 이번 글은 컴퓨터 구조에서 배웠던 내용 중 운영체제 과목을 이해하는 데 도움이 되는 토픽들을 정리해보는 시간을 가지겠습니다. 다룰 Content부터 소개하겠습니다.
Contetns
Bus
- Bottleneck
I/O Basic
- Event handling Mechanisms
- I/O 처리 기법
- I/O Device access
컴퓨터 시스템의 전체적인 구성 중에서 I/O의 동작원리에 대해서 중점적으로 알아볼 계획인데요. 또한 기법에 따른 성능 비교도 함께 소개할 예정입니다. CPU와 메모리같은 경우는 안정적인 Execution model들이 이미 많이 연구된터라 괜찮지만 I/O에 관한 이슈는 새로운 디바이스들이 나오면서 다시 리뷰해야 할 내용들이 많습니다.
08.01. Bus
단일 버스는 시스템 버스에 여러가지 디바이스들이 연결된 것입니다. CPU와 메모리, I/O장치들이 전부 하나의 System Bus에 물려있는 그림이 떠올려지신다면 맞습니다. CAN network도 하나의 예가 될 수 있겠군요. 여기서 중요한 것은 하나에 다 연결되어 있다는 점입니다. 과거에 각 장치들의 속도가 비슷했던 시기에는 상관이 없었습니다. 하지만 CPU, 메모리, I/O장치들의 속도 격차가 커지면서 병목현상(Bottleneck)이라는 것이 발생하죠.
CAN network란?
자동차에 사용하는 네트워크 프로세스와 데이터 를 주고받는 시스템. CAN 통신은 메시지 기반 프로토콜이며 최근에는 차량 뿐만 아니라 산업용 자동화기기나 의료용 장비에서도 종종 사용되고 있다. Controller Area Network (CAN)은 각 제어기들 간의 통신을 위해 주로 사용되는 non-host 버스 방식의 메시지 기반 네트워크 프 로토콜이다. CAN 네트워크에서 데이터를 전송하는 둘 이상의 노드가 있을 경우 충 돌이 발생할 수 있다. CAN 명세서에서는 우성(dominant) 비트와 열성 (recessive) 비트라는 용어를 사용한다. 우성 비트는 논리적인 비트값 0을 가지며, 예를 들어 전기적으로 신호값을 강제로 low로 내린다. 열 성 비트는 논리적인 비트값 1을 가지며, 예를 들어 전기적으로 high 상태에 머물러 있는다. 결론적으로 두 노드가 서로 동시에 0을 보내면 네트워크상에서 0이 지나가며, 둘 다 1이면 1이 지나간다. 그러나, 하나는 0이고 다른 하나는 1이라면 네트워크 상에는 0이 지나가게 된다. 우성 비트가 경쟁에서 이긴다는 뜻이다. 즉 CAN 네트워크는 낮은 CAN ID를 갖는 프레임에게 오류나 지연없이 데이터를 전송할 수 있는 기법을 제공한다. 경쟁에서 진 높은 CAN ID를 갖는 프레임은 우성 메 시지의 전송이 끝난 후 6 비트를 전송할 수 있는 시간을 추가로 기다 린 후 재전송을 자동으로 시작한다. 이러한 충돌 해결 방식 때문에, 자동화 시스템에서 CAN 버스는 실시간 우선순위 기반 통신 시스템으로 사랑받고 있다.
그럼 각장치의 속도는 어느 정도 일까요? CPU 2GHz, 8GHz.. 많이 들어보셨을 겁니다. 2GHz라면 1 clock에 걸리는 시간을 얼마일까요?
1clock / 2GHz = 0.5ns
I/O장치의 속도는 여러분들이 직접 생각해보시면 좋을 것 같습니다.(만약 CPU가 여러분의 키보드 타자 속도에 맞추어서 clock이 돌아간다면요? 끔찍하겠군요.)
CPU > 메모리 >> I/O장치
이러한 이유때문에 조립컴퓨터를 맞추시는 분들이 CPU의 성능만 고려하는 것이 아니라 메모리 성능도 고려하는 것입니다. 무식하게 CPU만 최고사양으로 맞추면 원하는 성능이 나오지 않습니다.
Pipeline 내용을 배우면서 Stall이라는 용어를 들어보셨을 겁니다. 하나의 버스내에 연결된 디바이스들 간 속도로 병목현상이 발생한다면 빠른 디바이스는 원래 자신이 처리하는 양만큼 처리하지 못하게 됩니다. 빠른 디바이스에 Stall이 생기는 것이죠. 이러면 전체 시스템 속도는 느린 디바이스의 속도에 의해 제한이 걸립니다. 어떻게 해결할 수 있을까요? 하나의 버스에 많은 디바이스들이 물려있다는 것이 문제였습니다.
버스 이중화 (Hierarchical approach)
Hierarchy하게 접근 빈도가 적고, 처리 속도가 느린 장치들을 따로 떼어 놓으면 됩니다. I.O Bus를 따로 연결하는 것이죠. 이렇게 하면 I/O Bus의 경우 표준화를 하여 어느 CPU와도 동작하도록 할 수 있는 장점도 있습니다. System Bus는 CPU마다 다를 수 밖에 없으니까 I/O Bus를 따로 떼어놓는다면 그것만 표준화 시킬 수 있게 된 것이죠.
여기서 Bridge Bus는 System bus의 상태를 보고 I/O Bus에 올라와 있는 것을 올려주는 역할을 한다고 생각하시면 됩니다.
08.02. I/O Basic
08.02.1. Interrupt_Event handling mechanisms
이벤트 처리 기법인 인터럽트(Interrupt)와 트랩(Trap)에 대해 알아보겠습니다. 인터럽트는 비동기적인 이벤트를 처리하기 위한 기법인데요. 여기서 비동기적이라는 것은 지금 하고 있는 컴퓨팅과 발생한 행위가 발생시점 측면에서 독립적으로 발생한 것입니다. 조금 어렵게 느껴지실 수 있는데요. 예를 들자면 네트워크 패킷 도착 이벤트나 I/O 요청등이 있습니다. 조금 더 자세히 설명하자면 카톡메시지를 생각해보죠. OS관점에서는 카톡인지 뭔지 모르겠는 패킷이 일단 도착한 것입니다. 비록 내가 카카오톡 프로그램을 실행중이더라도 메시지는 언제 올 지 모릅니다. 갑자기 날아온 것이죠. 이것이 바로 비동기적 이벤트입니다.
인터럽트 처리 순서
- 현재 실행 State 저장
- ISR : Interrupt Service Routine로 이동
- 저장한 State 복원
- 인터럽트로 중단된 지점부터 다시 시작
ISR(Interrupt Service Routine) or Interrupt Handler란?
인터럽트에 대응하여 특정 기능을 처리하는 기계어 코드 루틴. 커널 함수
일단 여기서 ISR은 짧아야 한다, 인터럽트에도 우선수위가 있다, Timersharing 또한 Timer 인터럽트의 도움으로 가능하다는 사실을 기억해둡시다.
먼저 ISR은 왜 짧아야 하는가?(ISR 시간)
위에서 네트워크 패킷 이벤트를 비동기적 이벤트의 예로 설명하였는데요. 패킷이 너무 많이 와 처리를 처리를 안해주면 어떻게 될까요? 잃어버립니다. 패킷은 잠시 보관될 뿐이죠. 따라서 ISR은 다른 인터럽트가 들어오기 전에 끝나줘야 합니다. 그래서 ISR이 굉장히 짧아야 하는 것입니다. DoS attack을 생각해보시면 됩니다. 서비스 거부 공격(Denial of Service Attack)은 시스템의 리소스를 부족하게 하여 원래 의도된 용도로 사용하지 못하게 합니다. 대량의 데이터 패킷을 통신망으로 보내고 특정 서버에 많은 접속 시도를 하여 다른 이용자가 정상적인 서비스를 이용하지 못하게 하는 것이죠. 이런 방법은 인터럽트 Fundamental을 abuse하는 것입니다.
하지만 그럼에도 불구하고 인터럽트가 동시에 발생하면 어떻게 될까요?(인터럽트 우선순위)
그래서 우선순위가 필요합니다. 물리적으로 동시에 네트워크 패킷 도착과 디스크 데이터 발견이 일어났다고 하면 우리는 무엇을 먼저 처리해야할지 고민이 필요합니다. 그렇다면 이러한 결정이 동적(Dynamic)으로 결정되어야 할지 정적(Static)으로 결정되어야 할지 고민해보아야 할 것입니다. 여기서 동적은 running time에 결정하는 것이고 정적은 시스템을 만들 때 결정하는 것이라고 생각하시면 됩니다. 동적으로 결정하면 우선순위가 뒤죽박죽되어 보안상 위험할 것 같죠? 실제로 정적으로 설정되어 있습니다.(위에서 네트워크 패킷 도착과 디스크 데이터 발견 둘 중 무엇이 우선순위가 더 높을까요?)
디스크 인터럽트보다 네트워크 인터럽트가 우선순위가 높습니다.
이러한 우선순위에는 다 이유가 있는데요. 위의 경우에서는 그 이유가 무엇인지 생각해보시면 좋을 것 같습니다.
네트워크 패킷은 잃어버릴 수 있지만 디스크에서 찾은 데이터는 PCI Bus와 버퍼들이 보존할 수 있습니다.
그렇다면 우선순위가 가장 높은 인터럽트는 무엇일까요? 여러분이 컴퓨터를 사용하면서 자주 사용하는 방법이 힌트입니다.(Crtl + alt + delete 등도 안 먹힐 때 무엇을 하시나요? 여러분들이 사용하는 최후수단을 떠올려 보세요.) 바로 NIM(Non-maskable interrupt)중 하나인 Power shut down 시퀀스입니다. 무시할 수 없고 mask가 불가능한 인터럽트라는 것이죠. 그러면 mask가 무엇인지 궁금하실 수 있는데요. Mask는 Memory management에서 배우는 flash와 유사합니다. Disable되는 것이죠.
Interrupt Classification(Interesting topic to study)
전원 관련 > 기계 착오 > 외부 신호 > 입출력 > 명령어 관련 착오 > 프로그램 > SVC(Supervisor Check = OS)
일반적으로 인터럽트 우선순위는 하드웨어 관련 인터럽트가 소프트웨어 관련 인터럽트보다 우선순위가 높고 내부 요인으로 인해 발생한 인터럽트보다 외부 요인으로 인해 발생한 인터럽트가 우선순위가 높습니다.
Timesharing 역시 timer 인터럽트의 도움으로 가능하다고 설명드렸는데요. 우리가 실시간 영상을 보면서 Conjunction CPU가 separate 할 때 소리가 끊어지거나 동기가 맞지 않는 일이 발생하는 원인 중 하나는 바로 이러한 인터럽트가 제시간에 이루어지지 않기 때문입니다.
Timer interrupt없이 timesharing이 가능할까? 라는 질문이 생기실 수 있습니다. 가능은 할 것입니다. 시간에 대한 것을 직접 가지고 있거나(실행된 instruction의 수를 counting하는 것도 하나의 방법이 될 수 있겠네요.) 프로그램을 실행하면서 시간을 보는 것인데요. 하지만 Clock 자체를 시간을 보는 행위에 사용한다는 것 자체가 효율성을 떨어뜨리는 것입니다. 물론 compiler의 도움을 받을 수도 있겠군요. 하지만 비효율적이고 compiler dependency로 인해 별로 좋은 선택은 아닐 것입니다. 따라서 Timer interrput를 통해서 timesharing하기 때문에 involutary switching이라고 표현하죠. 그에 반해 멀티 프로그래밍은 인터럽트 필요없이 I/O Routin을 보고 커널이 다른 프로그램을 올리는 방식이기 때문에 volutary switching이라고 합니다.
인터럽트 관련하여 추가적인 이슈들을 더 살펴보겠습니다.
Nested Interrupt(Interesting topic to study)
만약 Masked out된 인터럽트는 어떻게 될까요?
차례가 오면 실행할 것입니다. 하지만 버퍼에 데이터가 유지되고 있어야겠죠. 네트워크 패킷과 디스크 데이터 발견 인터럽트 중 네트워크 패킷 인터럽트가 우선순위가 높았던 이유이기도 합니다.
우선순위가 더 높은 인터럽트가 발생하면 어떻게 될까요?
인터럽트 실행 중 timesharing으로 인해 다른 프로그램으로 갈 수 있을까요? 만약 가게되면 어떤 일이 발생할까요?
위 두가지 질문은 결국 ISR에 소요되는 시간과 관련된 질문으로 귀결됩니다. 돌아가는 시간이 정확히 딱 얼마인지는 정해져 있지 않고요. 인터럽트가 어떻게 들어오느냐, 스케쥴링이 어떻게 되느냐에 따라 다르다고 생각하면 됩니다. 돌아오지 않을 수도 있겠네요.(인터럽트 발생 후 사용자가 프로그램을 죽일 경우가 있을 수 있습니다.)
인터럽트의 처리 과정에 대해서는 컴퓨터 구조 과목에서 하드웨어적인 부분을 복습하시면 보다 깊게 이해하실 수 있을 것입니다. CPU에 인터럽트 pin이 있죠. 관련된 데이터가 인터럽트 trigger가 됩니다.
08.02.2. Trap_Event handling mechanisms
두번째로 살펴볼 이벤트 처리 기법은 Trap입니다. 인터럽트는 비동기적 이벤트를 처리했다면 트랩은 동기적인 이벤트를 처리하기 위한 기법이라고 생각하시면 됩니다.
System call, Divide by zero
동기적 이벤트라는 것은 결국 현재 수행하고 있는 프로그램이 발생시킨 이벤트라고 생각하시면 됩니다. 시스템 콜도 결국 내가 프로그램을 수행하다가 커널 서비스가 필요하기 때문에 호출한 것이기 때문이죠. 시스템 콜이 무엇인지에 대해서는 아래의 글의 참고해주시면 됩니다.
2021.11.01 - [학부공부/운영체제] - 03. 운영체제 구조(1)
2021.11.02 - [학부공부/운영체제] - 06. System call [Interesting topic to study]
요약하자면 시스템 콜을 통해서 유저모드에서 커널모드로 바뀐다. 시스템 콜을 하면 시스템 콜 라이브러리를 통해 커널로 들어간다. Argument는 register, stack을 통해서 전달되는 방식으로 시스템 콜로 contorol이 넘어간다. 입니다. 여기서 시스템 콜 라이브러리가 시스템 콜에 해당하는 트랩을 걸어준다고 생각하시면 됩니다. 처리하는 방식은 인터럽트와 유사한데요. ISR과 비슷한 역할을 하는 친구가 있습니다. Trap handler, Trap Service Routine이죠. 중요한 차이점은 인터럽트와 달리 트랩이 동기적인 이벤트라 state를 저장하고 복원하는 행위를 하지 않는다는 것입니다. State를 저장하지 않기 때문에 인터럽트는 Context switching등을 통해 다른 프로세스를 실행하는 등 여러가지 경우가 있지만 트랩은 기본적으로 트랩이 발생했던 위치로 돌아갑니다. 또 한가지 차이점은 트랩은 우선순위가 존재하지 않습니다. 동기적으로 발생하기 때문에 발생하는 순서대로 처리하면 되거든요.
만약 트랩하는 도중 인터럽트가 발생한다면요?
state가 save되기 때문에 트랩이 발생했던 위치로 돌아가지 않을 수도 있습니다. 트랩이 원래 위치로 돌아가지 않는 예외적인 경우가 될 수 있겠네요.
트랩과 인터럽트가 동시에 발생한다면요?
인터럽트를 제대로 처리하려면 인터럽트를 먼저 처리되지 않을까 생각합니다. 이 부분에 대해서는 댓글로 여러분 의견을 남겨주시면 감사하겠습니다.
추가적으로 트랩이 디버깅하거나 개발할 때 잘못된 연산을 수정하는 방법을 제공하기 위해 고안되었다네요. 카더라 통신이라 확실하진 않습니다만 trp이 덫, 배나 항공기를 타고내릴 때 쓰는 사다리라는 뜻이 있기 때문에 그럴싸하게 들리긴 합니다.
글이 많이 길어졌는데요. 아주 흥미롭고 생각해볼 이슈들을 많이 제공해주는 토픽이여서 그랬던 것 같습니다. 다음 포스팅에서는 I/O device model, Polling, DMA등에 대해 다루겠습니다. 긴 글 읽어주셔서 감사하고 댓글 많이 남겨주시면 더욱 감사하겠습니다.(잘못된 내용 지적이나 질문은 언제나 대환영입니다.)
'학부공부 > OS_운영체제' 카테고리의 다른 글
10. Process(1) (0) | 2021.11.12 |
---|---|
09. 운영체제와 컴퓨터 구조(2) (0) | 2021.11.08 |
07. Hypervisor [Interesting topic to study] (0) | 2021.11.02 |
06. System call [Interesting topic to study] (0) | 2021.11.02 |
05. Multics vs Unix [Interesting topic to study] (0) | 2021.11.02 |
댓글