Issue 1. I/O
I/O devices와 CPU가 concurrently 동작할 수 있고, 데이터를 옮기는데는 오랜 시간이 걸린다 (device buffer -> main memory)까지
사실 반도체도 그렇고 모든 속도의 핵심은 메모리에 데이터를 올려놓는데 걸리는 시간을 줄이는 것,,
따라서 이러한 task를 할 때 CPU가 다른 일을 하도록 하는 것이 좋다.
Interrupts
kernel이 CPU가 다른 일을 하고 있을 때, I/O가 끝났다는 것을 알려줘야함 이때 방식에는 busy waiting과 Hardward interrupt가 있다.
Interrupt Handling
Interrupt가 들어왔을 때, user mode -> kernel mode
Preserves the state or the CPU
- 이전에 실행하고 있던 프로세스의 정보들이 담긴 register의 값을 저장해놔야함 system stack에 저장
Determines the type
Transfers control to the interrupt service routine or interrupt handler
Interrupt VS Exception
Interrupt의 경우 I/O와 같은 시그널이 들어온 경우, Exception은 코드 실행 중에 divde by zero와 같은 문제가 생겨서 handler로 이동하게 됨
Data Transfer Modes
각종 I/O device들에서 어쨌든 프로그램이 실행되려면 Memory로 데이터를 옮겨와야 한다. disk에서 바로 cpu로 옮기는 건 비효율적이기 때문에 DMAC라는 일종의 버퍼를 만들어서 BUS를 통해 데이터를 효율적으로 이동시킴
Programmed IO(PIO)
CPU가 data moving에 관여하는 경우 (ex. keyboard, mouse)
데이터양이 너무 많아질 경우 CPU 사이클을 소모해서 비효율적임
하지만 키보드나 마우스와 같이 한 번에 들어오는 데이터 양이 적을 때는 사용하는듯
DMA(Direct Memory Access)
Device controoler가 데이터 블럭을 로컬 buffer에서부터 main memory로 직접적으로 이동시킴
Issue2. Protection
user application이 system에 해를 끼치는 것을 막아야함
(disk drive에 직접 접근하거나, HLT instruction을 실행해버리는 이런 상황을 막아야됨)
=> Privileged instructions
CPU의 권한을 체크해서
- Direct I/O access
- Accessing system registers
- Memory state management
- HLT instruction in x86
위와 같은 task들을 할 수 있는 능력을 조절
Kernel mode vs user mode
privileged lebel, 즉 커널 모드에서만 protected instruction을 실행할 수 있도록 제한함!
Issue3. Servicing Requests
kernel 모드에서만 실행할 수 있는 instruction을 위해서 우리는 OS에게 특정 service를 요청해야함
그렇게 되면 모드가 바뀌고 kernel에서 요청 받는 instruction을 수행하고, 다시 원래의 user mode로 돌아오게 된다.
System Calls
system call이라는 것은 일종의 프로그래밍 인터페이스로, OS가 제공한다. OS는 request가 legal한지를 체크해서 시스템을 보호함
따라서 system call은 일종의 protected procedudre call이라고 볼 수 있겠다. 차이가 있다면 권한이 상승된다는 것!
실행 과정을 살펴본다면
1. 프로그램이 돌다가 system call을 호출함
2. OS에게 권한이 넘어가고, 적절한 호출인지를 판단
3. 합법하다면, kernel 모드에서 해당 호출이 실행된다.
4. 끝났다면, user mode로 돌아와서 나감
System call이 Procedure call보다 느린 이유
- 일반적인 Procedure call 같은 경우에는 instruction이 jump라면 그냥 바로 뛰지만, 시스템 콜의 경우 vlaid한지 아닌지를 체크해야한다.
- user -> kernel 모드로 바뀔 때 program state를 저장해야 함.
(자세히 얘기해보자면 프로세스 A가 user mode에서 돌고 있다가 kernel 모드로 가기 위해서는 현재 프로그램 state를 프로세스 A의 kernel stack에 저장하고, 기존에 커널 스택에 있던 애들을 현재 register로 불러옴) - Cache state도 바뀜
- Pipeline 효율이 떨어짐 (이후의 파이프라인 다 지워짐)
- TLB 바뀜
- address space가 바뀐다.
Exceptional Events
Interrupts
: Hardware deivce에 의해 유발됨 (asynchronous)
프로그램 수행과는 상관 없음
Exceptions
: software 실행 과정에서 유발(Synchronous)
Unintentional(Dived by zero)
Intentional(syscall ex. open, read,...)
(RISC-V에서는 이 두개를 모두 합쳐서 Trap이라고 부름)
X86에서는 Exception을 Trap / Faults / Aborts로 구분
Trap
Intentional / return to next
Fault (ex. Page fault(회복가능) / protection faults(unrecoverable))
Unintentional / return to current / possibly recoverable
Abort
Unintentional && Unrecoverable
Abort the current program
Issue4. Control
running program이 control을 CPU에게 안돌려주고 무한루프를 돌면 큰일 남,,,
따라서 CPU를 release하는 special system call이 필요함.
Timers
periodic interrupt를 발생시켜서 OS에게 control을 돌려줌 그러면 스케쥴러가 불리면서 해당 프로세스를 계속할 건지 다른 프로세스로 switching할 건지를 결정한다.
Timer는 priviledged !! OS만 해당 주기를 건드릴 수 있다.
Issue5. Memory Protection
다른 동작들은 application이 OS에게 요청을 하면, OS가 대신 수행해주는 방식인데 보통 메모리를 생각해보면 프로세스가 메모리에 접근할 때는 OS를 거치지 않고 직접적으로 접근함
그 이유는 메모리에 접근할 때마다 OS가 권한 체크를 해야하면 너무 오래 걸리기 때문임
하지만 서로 다른 application끼리 메모리 영역을 침범하지 않게 OS가 보호를 해주긴 해야함
access 가능한 주소 범위를 체크 (base <= access <= base + limit)
이런 방식은 주소가 연속적으로 배열되어야 한다는 한계
Issue6. Synchronization
concurrent하게 프로세스가 오며갈때 load / add / store 사이에 스위칭이 일어나면 문제 발생
atomic하게 묶기
