1. Context Swithcing

• CPU/코어에서 실행 중이던 프로세스/스레드를 다른 것으로 바꾸는 것

• 멀티프로세싱을 가능하게 해줌

1.1. 발생 조건

• 자신에게 주어진 timeslice를 다 사용하여 다른 프로세스/스레드에 넘길 때

• I/O 작업을 기다려야해서 다른 프로세스/스레드에 넘길 때

• interrupt가 발생하였을 때 등등

1.2. 동작

• 먼저 user mode에서 kernel 모드로 변경

• 레지스터 값들(PC, SP 등)을 PCB나 TCB에 저장

• 스케쥴러에 의해 다음 작업을 선정하고, 해당 작업의 PCB/TCB에서 레지스터값을 복원

• 다시 kernel mode로 바뀌며 작업 진행

1.3. 프로세스와 스레드에서의 context swithcing 차이

• 스레드는 code, data, heap메모리를 공유하기에 따로 메모리 관련해서 바꿔줘야 하는 것은 없음

• 프로세스는 메모리가 아예 바뀌는 것이므로 MMU(가상페이지에서의 메모리 주소를 물리메모리 주소로 바꾸어주는 것)도 수정해줘야하고, TLB(MMU관련한 캐시)도 flush해줘야 하고, Page Table도 교체해줘야 하는 추가적인 오버헤드가 발생

• Page Table은 커널 메모리에 프로세스 개수만큼 존재.
  각 PCB에서 자신의 page table의 주소를 저장하여 context switching일어나면 cpu의 PCBR에 해당 Page Table값을 넣어주어 page table을 교체함

• 둘 다 그냥 캐시는 안 바꿔서 context swithcing 발생하면 cache pollution(대량의 캐시 미스)이 발생할 수 있음. 물론 프로세스 context swithcing이 훨씬 발생 가능성 높음

2. 가상메모리

• 프로세스가 메모리를 혼자 사용하게 하는 것처럼 보여주는 기법

• 한정된 자원인 RAM에 여러 프로세스가 동시에 load되어 사용할 수 있게 해줌

• 프로세스 가상 메모리를 page 단위로 쪼개고, 이를 RAM의 frame에 load하여 사용 (external fragmentation 예방)

• CPU가 가상주소를 읽으려 하면, MMU(Memory Management Unit)가 페이지 테이블을 통해 물리 주소로 매핑

• 페이지 테이블 역시 메모리에 있으므로, 메모리에 2번 접근하게 됨. 따라서 MMU 부에 TLB 캐시를 사용하여 TLB에 없으면 페이지 테이블 가능 방식으로 오버헤드를 줄임

• 필요한 페이지만 RAM(프레임)에 로드(demand paging)하고, 부족 시 디스크에서 가져오며 페이지 폴트가 발생. 스와핑으로 덜 사용된 페이지를 디스크로 내쫓아 공간을 확보

2.1. 페이지 폴트

• 프로세스가 참조한 가상 메모리 페이지가 현재 물리 메모리(RAM)에 적재되어 있지 않을 때 발생 (TLB, Page Table로 확인)

• OS가 Storage에서 해당 페이지를 읽어 와 RAM에 올린 뒤, 다시 명령을 재실행

• I/O 작업이므로 오버헤드가 발생

2.2. 스왑

• 메모리가 꽉차서 더 이상 RAM에 페이지를 적재 불가능한 상황

• RAM에 적재된 페이지 중에 하나 골라 Storage의 스왑 영역으로 이동(swap-out)

• 그리고 Storage에서 페이지를 RAM에 로드(swap-in)

• 성능 하락

2.3. Thrasing

• RAM크기가 부족해 OS가 계속 디스크와 램사이에서 페이지를 나르기만(swap)하는 현상

• 성능 하락

• 메모리 크기를 늘리면 해결됨

2.4. 장단점

• 멀티태스킹 지원, 메모리 보안, 부족한 RAM을 효율적으로 사용, 외부 단편화 방지, 개발 용이함

• 내부 단편화 발생, 페이지 폴트로 인한 오버헤드

• 페이지테이블에 보안 비트를 사용하여, 해당 코드 또는 데이터가 읽기전용 영역인지를 알 수 있어, 보안을 제공