[CS] 운영체제의 메모리 관리 방식 페이징

목차

• 연속 메모리 할당
• 외부 단편화
• 페이징
• 페이지 테이블
• PTBR
• TLB
• 페이징에서의 주소 변환
• 페이지 테이블 엔트리

 

 

 

연속 메모리 할당

연속 메모리 할당: 프로세스에 연속적인 메모리 공간을 할당

 

문제점

• 외부 단편화
• 물리 메모리보다 큰 프로세스 실행 불가

 

 

스와핑

• 현재 사용되지 않는 프로세스들을 보조기억장치의 일부 영역으로 쫓아내고
• 그렇게 생긴 빈 공간에 새 프로세스 적재
• 지금 당장 사용하는 프로세스만 메모리에 적재

 

장점: 프로세스들이 요구하는 메모리 공간 크기 > 실제 메모리 크기

스왑 영역 크기 확인하기:  free, top 명령어

 

 

메모리 할당

• 프로세스는 메모리의 빈 공간에 할당되어야 한다... 빈 공간이 여러 개 있다면?
• 최초 적합: 적재할 프로세스를 빈 공간 A에 적재할 경우
• 최적 적합: 적재할 프로세스를 빈 공간 C에 적재할 경우
• 최악 적합: 적재할 프로세스를 빈 공간 B에 적재할 경우

 

연속 메모리 할당 3가지 방식

• 최초 적합 (first-fit)
• 운영체제가 메모리 내의 빈 공간을 순서대로 검색하다
• 적재할 수 있는 공간을 발견하면 그 공간에 프로세스를 배치하는 방식
• 검색 최소화, 빠른 할당

• 최적 적합(best-fit)
• 운영체제가 빈 공간을 모두 검색해본 뒤, 적재 가능한 가장 작은 공간에 할당

• 최악 적합(worst-fit)
• 운영체제가 빈 공간을 모두 검색해본 뒤, 적재 가능한 가장 큰 공간에 할당

 

 

 

 

외부 단편화

• 사실 프로세스를 연속적으로  메모리에 할당하는 방식은 메모리를 효율적으로 사용하는 방법이 아니다.
• 외부 단편화(external fragmentation) 이라는 문제가 발생하기 때문

 

• 사용자 영역이 200MB일 때
  • 크기가 50MB인 프로세스 A
  • 30MB인 프로세스 B
  • 100MB인 프로세스 C
  • 20MB인 프로세스 D를 차례대로 적재해야 한다면?

 

프로세스 B, 프로세스 D 실행 끝

 

빈 공간의 총합: 50MB

 

Q. 50MB 프로세스 할당 가능한가?

A. NO!! 빈 공간의 총합이 50MB 일지라도 어떠한 빈 공간에 50MB 프로세스를 적재할 수 없다.

 

외부 단편화 정리

• 프로세스들이 실행되고 종료되길 반복하며 메모리 사이 사이에 빈 공간 발생
• 외부 단편화
  • 프로세스를 할당하기 어려울 만큼 작은 메모리 공간들로 인해 메모리가 낭비되는 현상
  • 연속적인 메모리 할당은 외부 단편화라고 하는 문제를 야기하기 때문에 부작용이 있는 메모리 할당 방식

 

 

외부 단편화 해결

1. 메모리 압축 (compaction)

• 여기저기 흩어져 있는 빈 공간들을 하나로 모으는 방식
• 프로세스를 적당히 재배치시켜 흩어져 있는 작은 빈 공간들을 하나의 큰 빈 공간으로 만드는 방법

 

 

2. 페이징

• 현재 운영체제가 선택한 가장 대중적인 메모리 관리 기법

 

페이징을 통한 가상 메모리 관리

• 가상 메모리이란?
• 실행하고자 하는 프로그램을 일부만 메모리에 적재하여
• 실제 물리 메모리 크기보다 더 큰 프로세스를 실행할 수 있게 하는 기술
• 페이징, 세그멘테이션

 

페이징이란?

• 외부 단편화가 발생했던 근본적인 문제?
• 각기 다른 크기의 프로세스가 메모리에 연속적으로 할당되었기 때문

 

 

프로세스를 일정 크기로 자르고, 이를 메모리에 불연속적으로 할당할 수 있다면 어떨까?

• 당연하게도 외부 단편화는 발생하지 않을 것이다.

 

• 페이징(paging)
  • 프로세스의 논리 주소 공간을 페이지(page) 라는 일정 단위로 자르고,
  • 메모리의 물리 주소 공간을 프레임(frame) 이라는 페이지와 동일한 일정한 단위로 자른 뒤
  • 페이지를 프레임에 할당하는 가상 메모리 관리 기법

 

페이징에서의 스와핑

• 프로세스 단위의 스왑 인, 스왑 아웃이 아닌 페이지 단위의 스왑 인(페이지 인), 스왑 아웃(페이지 아웃)
• 메모리에 적재될 필요가 없는 페이지들은 보조기억장치로 스왑 아웃
• 실행에 필요한 페이지들은 메모리로 스왑 인

 

 

• 프로세스를 실행하기 위해 모든 페이지가 적재될 필요가 없다.
• 프로세스를 이루고 있는 모든 페이지가 메모리에 위치해 있을 필요는 없고
• 일부 페이지는 보조기억장치의 스왑영역에 있도 실행이 가능
• 달리 말해 물리 메모리보다 큰 프로세스도 실행될 수 있다.

 

 

연속적으로 할당되는 방식과 달리 메모리에 불연속적으로 할당되어 있는 페이지를

CPU는 어디에 있는지 알고 어떻게 알고 찾아갈 수 있을까요?

 

생기는 문제

• 프로세스를 이루는 페이지가 어느 프레임에 적재되어 있는지 CPU가 일일이 알기란 어렵다
• 프로세스가 메모리에 불연속적으로 배치되어 있다면 CPU 입장에서 이를 순차적으로 실행할 수가 없음
• CPU 입장에서 '다음에 실행할 명령어 위치' 를 찾기가 어려워짐

 

페이지 테이블

• 페이지 테이블
  • (실제 메모리 내의 주소인) 물리 주소에 불 연속적으로 배치되더라도
  • (CPU가 바라보는 주소인) 논리 주소에 연속적으로 배치되도록 하는 방법
  • 페이지 번호와 프레임 번호를 짝지어 주는 일종의 이정표

 

프로세스마다 페이지 테이블이 있다!

 

• 물리적으로는 분산되어 저장되어 있더라도 CPU 입장에서 바라본 논리 주소는 연속적으로 보임
• CPU는 그저 논리 주소를 순차적으로 실행하면 될 뿐

 

 

 

내부 단편화

• 페이지 크기가 10KB, 프로세스 크기 108KB
• 2KB: 내부 단편화
• 하나의 페이지 크기보다 작은 크기로 발생
• 하지만 내부 단편화는 외부 단편화보다 메모리 낭비가 작다.

대형 페이지라고 하는 예외적인 큰 페이지도 존재한다.

 

 

PTBR

• 프로세스마다 페이지 테이블이 있고,
• 각 페이지 테이블은 CPU 내의 프로세스 테이블 베이스 레지스터(PTBR)가 가리킨다.

 

이렇게 페이지 테이블이 메모리에 저장되어 있으면 어떤 문제가 생길까요?

• 그런데 페이지 테이블이 메모리에 있으면? => 메모리 접근 시간 두 배로
• 페이지 테이블 참조하기 위해 한 번
• 페이지 참조하기 위해 한 번

 

 

TLB

• TLB: CPU 곁에 페이지 테이블의 캐시 메모리
• 페이지 테이블의 일부를 가져와 저장

 

• CPU가 접근하려는 논리 주소가 TLB에 있다면? => TLB 히트
  • 메모리 접근 한 번
• CPU가 접근하려는 논리 주소가 TLB에 있다면? => TLB 미스
  • 메모리 접근 두 번

 

 

페이징에서의 주소 변환

• 특정 주소에 접근하고자 한다면 어떤 정보가 필요할까?
  1. 어떤 페이지/프레임에 접근하고 싶은지
  2. 접근하려는 주소가 그 페이지 혹은 프레임으로부터 얼마나 떨어져 있는지

 

 

페이징 시스템에서의 논리 주소

• 페이지 번호(page number)와 변위(offset)

 

• <페이지 번호, 변위>로 이루어진 논리 주소는
• 페이지 테이블을 통해
• <프레임 번호, 변위>로 변환된다.
• 페이지의 크기와 프레임의 크기는 같으므로 변위는 변하지 않는다.

 

논리주소(<페이지 번호, 번위>)가 <5,2>인 곳에 접근 가정

 

 

페이지 테이블 엔트리

• 페이지 테이블의 각각의 행: 페이지 테이블 엔트리(PTE)
  • 현재까지 설명한 PTE: 페이지 번호, 프레임 번호
  • 이외에 담기는 정보?

 

 

페이지 테이블 내에 담기는 정보

유효비트

• 현재 해당 페이지에 접근 가능한지 여부
• 현제 페이지가 스왑 영역으로 쫓겨나 있는지?
• 현재 페이지가 메모리에 적재되어 있는지?

1은 메모리에 존재, 0이면 현재 메모리에 없다.

 

 

만약 유효 비트가 0인 페이지에 접근하려고 하면?

• 페이지 폴트(page fault)라는 인터럽트 발생

 

 

보호 비트

• 페이지 보호 기능을 위해 존재하는 비트
• 읽기 전용 페이지(코드 영역)
• 페이지에 접근할 권한을 제한해서 페이지를 보호하는 비트

 

 

 

 

참조 비트

• CPU가 이 페이지에 접근한 적이 있는지 여부

 

수정 비트(dirty bit)

• CPU가 이 페이지에 데이터를 쓴 적이 있는지 여부

 

수정 비트의 존재 이유?

• 페이지 A를 수정한적이 없다면 A는 메모리에 있는 내용과 보조기억장치에 있는 내용이 똑같을 것이다.

 

수정된 페이지는 스왑 아웃될 때 보조기억장치에도 쓰기 작업을 거쳐야 한다.

(수정비트는 보조기억장치에서도 반영을 해야 된다 판단하기 위해서 존재)

 

 

 

해당 포스팅에 나온 글과 이미지들은 강민철 저자님의 혼자 공부하는 컴퓨터 구조 + 운영체제의 책과 강의를 참고하여 만들어졌습니다.

책에서 보다 깊게 나오는 내용이 있으므로 한번 구매하고 보셔도 좋을 것 같습니다.

[한빛미디어] 혼자 공부하는 컴퓨터 구조+운영체제