on
운영체제 - 19
KOCW 운영체제 19강
양희재 교수님 강의를 듣고 쓴 글입니다.
Main Memory Management
OS에서 CPU자원은 process management
에서 관리한다. 그리고 주기억장치 관리는 Main Memory Management
에서 관리한다.
Contiguous Memory Allocation(연속 메모리 할당)
OS가 없던 시절의 컴퓨터는 main memory에 process만 올라갔었다. OS가 생긴 후에는 main memory에 OS와 process가 올라가게 됐다.
그러나 기술이 발전함에 따라 multi-programming 환경으로 바뀌었다. → 하나의 main memory에 여러개의 process가 loaded.
-
booting 직후 메모리 상태
당연하게도 main memory에는 OS밖에 없다. 부팅 직후의 main memory에는 OS와 큰 구멍이 하나 생긴다. (아직 다른 process가 올라오기 전이기 때문이다.)
-
process 가 생성과 종료를 반복할 때 메모리 상태
생성과 종료를 반복하면 이 때까지 우리가 배운 상식으로는 이렇게 된다고 알고있다. 그리고 결과적으로 메모리의 상태가 맨 오른쪽 그림과 같이 되는 것이다.
그래서 뭐가 문제인데?
위 그림을 보면 ‘저게 왜?’ 라는 생각이 들 수 있다. 하지만 우리는 또 다른 process를 메모리에 올려야 하는 상황을 또 생각해야만 한다. 아래 예시 그림을 보면서 뭐가 문제인지 보도록 하자.
이렇게 새로운 process인 process 4
가 메모리에 올라오려고 한다. 그러나 메모리에 올리려고 하려고 보니깐, hole의 공간이 부족한 것이다. (나머지 빈 공간과 hole의 공간을 합친 크기는 process 4
보다 크다고 생각하자.)
이번엔 위 과정이 더 많이 진행된 후의 메모리 상황을 보도록 하자.
보면 알 수 있듯이 많은 hole들이 메모리에 있다. 프로세스는 메모리에 연속적으로 올라와 모여있기 때문에 hole 크기들의 합이 클지라도 작은 크기로 나눠져 있으면 프로세스를 메모리에 load하지 못한다. 그래서 다음과 같은 방법으로 이 외부 단편화 현상을 해결할 수 있다.
- 메모리에 올라가 있는 프로세스를 옮기기 →
Compaction
메모리에 있는 프로세스를 한곳으로 모은다! 굉장히 큰 부담. - hole에 적절한 크기의 프로세스를 올리기 →
First-fit
,Best-fit
,Worst-fit
First-fit
: 메모리에서 프로세스를 올릴 공간을 차례대로 보다가 맨 첫번째로 들어갈 수 있는 공간이 있으면 메모리의 해당 자리에 프로세스 load.Best-fit
: load될 프로세스의 크기와 중간에 비어있는 공간의 크기가 가장 비슷한 곳에 load.Worst-fit
: load될 프로세스의 크기와 중간에 비어있는 공간의 크기 차이가 가장 큰 곳에 load.- 속도 면에서는
First-fit
이 우위고, 메모리 이용률에서는First-fit,Best-fit
이 좋다고 한다. - BUT!! 이렇게 해도 외부 단편화로 인한 메모리 낭비가 30%나 된다는 것 → 다른 방안이 필요
- 메모리에 있는 프로세스가 종료되어 충분한 연속적인 크기가 생길 때까지 기다려야만 한다. → 결국엔 문제를 해결 못한 것.
결국엔 위 방법들도 근본적인 해결책이 될 수 없다.
오히려 Process를 자르기?
지금 문제는 남은 공간에 프로세스를 올려야 하는데 공간이 모두 자잘자잘하게 흩어져서 못 올린다는 것
→ 프로세스가 연속해서 올라가기 때문.
따라서 프로세스를 나눠서 올려보자. CPU는 주소에 접근할 때 마치 연속적인것처럼 인식하게 속이고, MMU라는 곳에서 메모리의 실제 주소와 매핑시켜서 해결할 수 있다.
- 나눠진 프로세스 :
page
라고 부른다 - 나눠진 메모리 :
frame
이라고 부른다
이제 그림으로 어떻게 주소변환이 진행되는지 살펴보자.
Address Translation
- Logical address
- CPU가 보는 주소. 2진수 표현.
- 하위 n bit는
offset
ordisplacement
. - 상위 m~n bit는
page #
.
- logical address → physical address
Page #
는 page table의 index값.page #
에 해당하는 table 내용이frame #
displacement
는 변하지 않는다.
CPU가 메모리의 50번지에 접근하는 과정
-
상황과 가정 + 이해해야할 것들
- 주소는 8bit로 표현한다고 하자.
page size
는 16byte라고 하자. 그렇게 되면displacement
는 page size를 얼마로 하냐에 따라서 정해지기 때문에 4bit가 된다.(초록색 범위)- m~n까지의 bit는
page #
이므로 빨간색으로 표시. page table
에는 위 그림에 해당하는frame #
의 값들이 들어가 있었다고 하자.
-
CPU가 메모리의 50번지에 접근하려고 한다.
2진수로 바꿔서 표현하면 위와 같다. 따라서
page #
: 00112 → 310displacement
: 00102 → 210
-
CPU → page table → 메모리
-
#1 : CPU가 메모리 50번지에 접근하기 위해 page table로 보냈다.
-
#2 :
page # = 3
,displacement = 2
라고 CPU가 보냈기에 해당하는page #
의 값과 mapping해서 메모리로 보낸다. -
#3 : 메모리의
frame #
에 해당하는 곳으로 접근. 그 후 해당 frame의 처음부터displacement
만큼 떨어진 곳으로 접근.→ 8번째 frame의 2만큼 떨어진 곳에 접근! 따라서 실제 메모리 128번지에서 2만큼 떨어진 130번지에 접근하게 되는 것.
CPU가 내는 logical address 50번지는 실제로 main memory의 physical address 130번지에 위치하는 것이다.
-
-
process1이 나눠져서 위 그림에 해당하는 page table에 의해 메모리에 올라간 결과
→ 이런식으로 CPU를 속이는 것이다. CPU는 프로세스가 연속적으로 모여있는 것처럼 보고, 실제 프로세스는 흩어져서 매핑 되는 것이다.