서울대학교 컴퓨터공학과 김진수 교수님의 "고급 운영체제" 강의를 필기한 내용입니다.
다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.
Monolithic kernel, Microkernel
- Monolithic kernel <-> Microkernel
- Monolithic 은 한덩이의 큰 커널
- Microkernel 은 진짜 중요한 것만 남기고 나머지는 전부 userspace 에서 돌리는
- 이렇게 하면 (Kernel 의 크기가 작기 때문에) Kernel panic 의 가능성이 적다.
- 하지만 요즘은 유행이 좀 시들하댄다
- Userspace 에서 돌리더라도 결국에는 Kernel function call 이 필요한데 monolithic 에서는 그냥 하나의 function call 이면 될 것을 microkernel 에서는 동일한 기능이라 할 지라도 Userspace 를 거쳐서 Kernel function call 이 이루어지니까
Views of OS
- Process management: CPU 의 abstraction
- Scheduler, IPC, Sync 등
- Memory management: MEM 의 abstraction
- Virtual memory, page caching, swap 등
- 나머지는 전부 IO 인데..
- 그중 FS Management 는 무조건 있어야 하는 거니까
- 이외의 IO management (Device driver)
- HW Control (interrupt 등)
Application 관점에서의 OS
- OS 는 결국에는 Computer System 에 대한 Abstract 이다
- Process, Thread 로 CPU 를 추상화해서 사용할 수 있도록 하고
- Virtual memory 로 MEM 을 추상화해서 사용할 수 있도록 하는 등
System 관점에서의 OS
- 한정된 자원의:
- 공유
- (공유하면서 동시에) 보호
- (공유함에 있어서) 형평성
- 효율성
- 를 관리해주는 소프트웨어인 것.
Implementation view
- OS 는 highly-concurrent, event-driven SW 이다
- syscall 만 생각해도 event-driven 이라는 것이 딱 감이 올 것이다
- Event 는 syscall 과 interruptions 로 구분지을수 있다
- syscall 은 userspace 에서 오는 event
- interrupt 는 hw 에서 오는 event
- Highly-concurrent 라는 것은 이러한 event 들이 nested 되기도 하며 수도 없이 쏟아지기 때문이다
여기부터는
2024-03-14강의
- syscall 이나 interrupt 가 겹칠때 어떻게 되냐
- syscall 수행중에 syscall 이 오는 경우
- 일단 single core 에서는 발생하지 않는다: 이미 kernel space 로 진입해 handler 가 불리고 있으므로
- multi core 에서는 가능하다: 다른 코어에서 user space 로 실행되다가 걔가 syscall 을 호출할 수 있기 때문
- syscall 수행중에 interrupt 가 오는 경우
- 당연히 single, multi core 모두 가능하다: interrpt 는 hw 에서 오는 것이기 때문
- interrupt 수행중에 syscall 이 오는 경우
- multicore 는 가능하고 singlecore 은 불가능하다: 마찬가지로 kernel space 로 실행중이었으니까
- interrupt 수행중에 interrupt 가 오는 경우
- 당연히 둘다 된다: hw-driven event 이기 때문
- syscall 수행중에 syscall 이 오는 경우
- Big kernel lock: 옛날에는 multi-core 에서 syscall 처리중에는 또 다른 syscall 이 오는 경우를 막기 위해 이렇게 kernel level lock 을 걸어버리는 괴상한 짓을 했다고 한다. (Giant lock)