운영체제 10. 가상 메모리 관리 (2) - SW components

출처 : https://www.youtube.com/watch?v=1gHHBa8UTjM&list=PLBrGAFAIyf5rby7QylRc6JxU5lzQ9c4tN&index=33

 

 

지난 시간에는 시스템의 성능을 높이기 위한 가상 메모리 관리의 필요성, 성능의 기준을 세우기 위한 page fault를 기반으로한 cost model을 정의하고, 가상 메모리 관리를 위해 필요한 HW components(Bit vectors)를 배웠다.

 

이번 시간에는 가상 메모리의 성능을 향상시키기 위해 사용할 수 있는 SW component들을 배운다.

 

 

Software Components

 

• 가상 메모리 성능 향상을 위한 관리 기법들
  • Allocation strategies (할당 기법)
  • Fetch strategies
  • Placement strategies (배치 기법)
  • Replacement strategies (교체 기법)
  • Cleaning strategies (정리 기법)
  • Load control strategies (부하 조절 기법)

 

 

Allocation strategies

 

• 각 프로세스에게 메모리를 얼마 만큼 줄 것인가?
  • Fixed allocation (고정 할당)
    • 프로세스의 실행 동안 고정된 크기의 메모리 할당
  • Variable allocation (가변 할당)
    • 프로세스의 실행 동안 할당하는 메모리의 크기가 유동적

 

• 고려사항
  • 프로세스 실행에 필요한 메모리 양을 예측해야 함
  • 너무 큰 메모리 할당 (Too much allocation),
    • 메모리가 낭비 됨
  • 너무 적은 메모리 할당 (Too small allocation),
    • Page fault rate 가 많이 발생하게 됨
    • 시스템 성능 저하

 

 

Fetch Strategies (가져오는 전략)

 

• 특정 page를 메모리에 언제 적재할 것인가?
  • Demand fetch (demand paging) : 요구할 때 가져옴
    • 프로세스가 참조하는 페이지들만 적재
    • Page fault overhead
  • Anticipatory fetch (pre-paging) : 예상해서 가져옴
    • 참조될 가능이 높은 page 예측
    • 가까운 미래에 참조될 가능성이 높은 page를 미리 적재
    • 예측 성공 시, page fault overhead가 없음, 예측 실패시 overhead가 큼
    • Prediction overhead(예측해야하는 overhead가 발생) (Kernel의 개입), Hit ratio에 민감함

 

• 실제 대부분의 시스템은 Demand fetch 기법을 사용
  • 일반적으로 준수한 성능을 보여줌
  • Anticipatory fetch
    • Prediction overhead, 예측하는 것이 쉽지않고, 잘못된 예측 시 자원 낭비가 큼

 

 

Placement Strategies

 

• Page / Segment를 어디에 적재할 것인가?
• Paging system에는 불필요. paging system에서는 page frame의 크기가 일정하기 때문

 

• Segmentation system에서의 배치 기법. 메모리의 빈 공간이 여러 곳일 때, 어디에 적재할 것인가
  • First-fit
  • Best-fit
  • Worst-fit
  • Next-fit

 

 

Replacement Strategies

 

• 비어있는 page frame이 없을 때, 새로운 page를 어떤 page와 교체할 것 인가?
  • Fixed allocation을 위한 교체 기법
  • Variable allocation을 위한 교체 기법
  • 나중 강의에서 자세히 살펴볼 예정

 

 

Cleaning Strategies

 

저번 시간에 HW component에서 update bit = dirty bit를 배웠다. 이 dirty bit(update bit)가 1일 때( = memory에 있는 데이터와 swap device에 있는 데이터가 다를 때), 언제 update bit를 0으로 만들어 줄 것인가(변경된 데이터를 swap device에 반영할 것인가)?

• 변경 된 page를 언제 write-back 할 것인가?
  • 변경된 내용을 swap device에 반영
  • Demand cleaning
    • 해당 page에 메모리에서 내려올 때 write-back
  • Anticipatory cleaning (pre-cleaning)
    • 더 이상 변경될 가능성이 없다고 판단 할 때, 미리 write-back
    • Page 교체 시 발생하는 write-back 시간 절약
    • Write-back 이후, page 내용이 수정되면, overhead!

 

• 실제 대부분의 시스템은 Demand cleaning 기법 사용
  • 일반적으로 준수한 성능을 보여줌
  • Anticipatory cleaning
    • Prediction overhead, 잘못된 예측 시 자원 낭비가 큼

 

 

Load Control Strategies

 

• 시스템의 multi-programming degree 조절. 처리하는 프로세스의 양을 조절
  • Allocation strategies와 연계 됨

 

• 적정 수준의 multi-programming degree를 유지해야 함
  • Plateau(고원) 영역으로 유지
  • 저부하 상태 (Under-loaded), multi-programming degree를 너무 낮게 설정하면
    • 시스템 자원 낭비, 성능 저하
  • 고부하 상태 (Over-loaded), multi-programming degree를 너무 높게 설정하면
    • 자원에 대한 경쟁 심화, 성능 저하
    • Thrashing(스레싱) 현상 발생
      • 과도한 page fault가 발생하는 현상

 

x축을 multi-programming degree, y축을 throughput이라고 했을 때, underloaded일 때는 multiprogramming degree가 증가할수록 throughput이 증가한다.

 

계속 증가하다가 multiprogramming degree가 일정 수준에 도달하면 throughput이 거의 변하지 않는 평탄한 상태가 지속된다. 이 상태를 plateau 라고 한다. 이 plateau 상태가 적정 수준이 된다.

 

이 plateau 상태에서 multiprogramming degree를 더 늘리면 throughput이 급격하게 떨어지게 된다. 너무 많은 프로세스들이 메모리를 요청하게 됨으로써, page fault가 심하게 발생(=thrashing)하게 되기 때문이다.