Notice
Recent Posts
«   2024/09   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
Archives
관리 메뉴

교대최소제곱법

[운영체제 part 3] 메모리 할당 본문

CS 기초/운영체제

[운영체제 part 3] 메모리 할당

옐라크레 2023. 9. 8. 16:55

메모리 할당

스와핑 : 안 쓰는 메모리를 보조기억장치로 보내는 방법

→ 요구하는 메모리가 실제 메모리보다 크더라도 실행 가능

but 애초에 덩어리가 커버리면 실행 불가함

메모리 할당 알고리즘

최초 적합 / 최적 적합 / 최악 적합 : 다 비효율적임 → 외부 단편화 때문에

*외부 단편화 : 메모리 사이사이 공간이 발생, 메모리 낭비

외부 단편화 해결방법

  1. 메모리 압축 : 잘 안씀
  2. 페이징(goat)

페이징

모든 프로세스를 페이지라는 일정한 크기로 짜르고

메모리를 프레임으로 일정하게 짤라서 할당

  • 페이지 단위로 스와핑도 가능(페이지 인, 페이지 아웃)
    = 프로세스에서 필요한 페이지만 담으면 되는거 아님? → 큰 프로세스도 실행 가능

또한 메모리에 불연속적으로 흩어 놓아 저장 가능 → 순차적 실행에 어려움이 있음

 

그래서 페이지 테이블을 생성해서 해결! like 전화번호부

→ 실제로는 바라바라지만 논리적으로는 붙어 있다고 보는 거임!

 

내부단편화 문제가 아직 있음 → 페이지 단위로 안짤리면 어카지? → 꼬투리가 남아서 내부단편화 발생

근데 이 정도면 외부단편화에 비해 귀여운 편

 

페이지 테이블 관리

PTBR(프로세스 테이블 베이스 레지스터)

각 페이지 테이블의 메모리 주소를 가르키는 레지스터

→ 메모리 접근이 두배로 늘어남

TLB : 그래서 캐시메모리에 저장했습니다!

 

페이징 주소 변환

페이지 번호 + 변위로 구성

페이지 테이블로 지나가면 → 페이지변호가 프레임 번호로 변경

이때 변위는 같은데 → 프레임과 페이지의 크기가 같기 때문

 

페이지 테이블

  • 페이지 번호, 프레임 번호
  • 유효 비트(페이지 접근 가능여부) → 메모리에 없으면 인터럽트 발생 → 페이지 폴트 처리 → 보조기억에서 가져와라!
  • 보호 비트 : 읽기 쓰기 실행을 나눠서 보호
  • 참조 비트 : history를 기록
  • 수정 비트(dirty bit) : 수정여부를 기록 → 스와핑할 때 그대로 옮길지 수정해서 옮길지를 결정

 

요구 페이징 : 필요한 페이지만 적재하는 기법 → 유효비트 활용

  • 페이지 교체 : 메모리가 꽉 찼을 때 사용

페이지 교체 알고리즘 → 페이지 폴트를 적게 발생해야 함

  • 페이지 참조열 : 페이지 폴트를 확인 할 수 있는 로그
  1. FIFO 페이지 교체 : 오래 머물렀으면 나가라
  2. 2차 기회 페이지 교체 알고리즘 : 한 번 참조한 적 있으면 최근으로 변경 = 한 번 더 사이클을 버틸 수 있음
  3. 최적 페이지 알고리즘 : 앞으로의 사용 빈도를 고려
    구현이 너무 어려움 → 앞으로의 사용 빈도를 어캐앎? → 이게 최고니까 정답지로 활용
  4. LRU : 가장 오래 사용되지 않은 페이지(과거)

페이지 폴트의 원인은 프레임 자체의 수가 적어서인 경우가 더 많다!!

스래싱 : 페이지 교체를 더 많이 하네;;

→ 동시에 실행되는 프로세스 수를 늘린다고 cpu 이용률이 높아지는게 아님

why? 메모리 교체만 주구장창 하는 것일 수도

즉, 프로세스 당 프레임의 수가 적절하게 주어져야한다!!

 

프레임 할당 방법

  1. 균등 할당, 비례 할당 : 정적 할당 방식 → 크기가 크다고 필요로 하는 프레임 수가 항상 많은건 아님
  2. 작업 집합 모델 : 특정 시간동안 주로 참조한 페이지 개수만큼만 프레임을 할당 → 참조 지역성
  3. 페이지 폴트 빈도 기반 : 페이지 폴트율이 너무 높으면 프레임이 부족한 것이다 라는 가정

+ COW (copy on write)

쓰기 시 복사 : 생성시간 단축, 메모리 절약

쓰기 작업이 없다면 페이지 테이블에서 같은 프레임을 가르킴

= 자식-부모 생성과정인 fork-exec 작업이 효율적인 이유

 

계층적 페이징

프로세스 테이블의 크기도 무시 못함

페이지 테이블을 관리하는 페이지 테이블을 형성한다 → 필요한 페이지 테이블만 메모리에 넣어둔다

이 경우 “outer 페이지 테이블 번호 - 페이지 테이블 번호 - 변위” 로 구성

but 계층이 많아지면 페이지 폴트시 참조해야할 횟수가 많아져서 느려짐