연속 메모리 할당
프로세스에 연속적인 메모리 공간을 할당하는 방식을 연속 메모리 할당 방식이라 한다.
스와핑
메모리에 적재된 프로세스들 중에는 현재 실행되지 않는 프로세스가 있을 수 있다. 이러한 프로세스들을 임시로 보조기억장치 일부 영역으로 쫓아내고, 그렇게 해서 생긴 메모리 상의 빈 공간에 다른 프로세스를 적재하여 실행하는 방식을 스와핑이라 한다.
이때 프로세스들이 쫓겨나는 보조기억장치의 일부 영역을 스왑 영역이라 한다. 그리고 실행되지 않는 프로세스가 메모리에서 스왑 영역으로 옮겨지는 것을 스왑 아웃, 반대로 스왑 영역에 있던 프로세스가 다시 메모리로 옮겨오는 것을 스왑 인이라고 한다. 스와 아웃 되었던 프로세스가 다시 스왑 인될 때는 스왑 아웃되기 전의 물리 주소와 다른 주소에 적재될 수 있다.
스와핑을 이용하면 프로세스들(단일 프로세스 X)이 요구하는 메모리 주소 공간의 크기가 실제 메모리 크기보다 큰 경우에도 프로세스들을 동시 실행할 수 있다.
메모리 할당
프로세스는 메모리 내의 빈 공간에 적재되어야 한다. 빈 공간이 여러 개 있다면 어디에 배치해야 할까? 대표적으로 최초 적합, 최적 적합, 최악 적합 세 가지 배치 방식이 있다.
- 최초 적합
최초 적합은 운영체제가 메모리 내의 빈 공간을 순서대로 검색하다가 적재할 수 있는 공간을 발견하면 그 공간에 프로세스를 배치하는 방식이다. 최초 적합 방식은 프로세스가 적재될 수 있는 공간을 발견하는 즉시 메모리를 할당하는 방식이므로 검색을 최소화할 수 있고 결과적으로 빠른 할당이 가능하다.
- 최적 적합
최적 적합은 운영체제가 빈 공간을 모두 검색해 본 후, 프로세스가 적재될 수 있는 공간 중 가장 작은 공간에 프로세스를 배치하는 방식이다.
- 최악 적합
최악 적합은 운영체제가 빈 공간을 모두 검색해 본 후, 프로세스가 적재될 수 있는 공간 중 가장 큰 공간에 프로세스를 배치하는 방식이다.
외부 단편화
연속 메모리 할당은 외부 단편화라는 문제를 내포하고 있다. 프로세스들이 메모리에 연속적으로 할당되는 환경에서는 프로세스들이 실행되고 종료되기를 반복하며 메모리 사이사이에 빈 공간들이 생긴다. 프로세스 바깥에 생기는 이러한 빈 공간들은 분명 빈 공간이지만 그 공간보다 큰 프로세스를 적재하기 어려운 상황이 발생되고, 결국 메모리 낭비로 이어진다. 이를 외부 단편화라 한다.
외부 단편화를 해결할 수 있는 대표적인 방안으로 메모리를 압축하는 방법이 있다. 메모리 조각 모음이라고도 부른다. 압축은 여기저기 흩어져 있는 빈 공간들을 하나로 모으는 방식으로 메모리 내에 저장된 프로세스를 적당히 재배치시켜 여기저기 흩어져 있는 작은 빈 공간들을 하나의 큰 빈 공간으로 만드는 방법이다.
하지만 압축 방식은 작은 빈 공간들을 하나로 모으는 동안 시스템은 하던 일을 중지해야 하고, 메모리에 있는 내용을 옮기는 작업은 많은 오버헤드를 야기하며, 어떤 프로세스를 어떻게 움직여야 오버헤드를 최소화하며 압축할 수 있는지에 대한 명확한 방법을 결정하기 어렵다는 단점이 있다. 이에 다른 해결 방안이 등장했는데 이것이 가상 메모리 기법 중 페이징 기법이다.
페이징을 통한 가상 메모리 관리
가상 메모리는 실행하고자 하는 프로그램을 일부만 메모리에 적재하여 실제 물리 메모리 크기보다 더 큰 프로세스를 실행할 수 있게 하는 기술이다. 이러한 가상 메모리 관리 기법에는 크게 페이징과 세그멘테이션이 있는데 이 책에서는 페이징 위주로 다룬다. 페이징 기법을 이용하면 물리 메모리보다 큰 프로세스를 실행할 수 있을 뿐만 아니라 앞선 절에서 배운 외부 단편화 문제도 해결 가능하다.
페이징이란
외부 단편화가 생긴 근본적인 이유는 각기 다른 크기의 프로세스가 메모리에 연속적으로 할당되었기 때문이다. 만약 메모리와 프로세스를 일정한 단위로 자르고, 이를 메모리에 불연속적으로도 할당할 수만 있다면 외부 단편화는 발생하지 않는다. 이것이 페이징이다. 페이징은 프로세스의 논리 주소 공간을 페이지라는 일정한 단위로 자르고, 메모리 물리 주소 공간을 프레임이라는 페이지와 동일한 크기의 일정한 단위로 자른 뒤 페이지를 프레임에 할당하는 가상 메모리 관리 기법이다.
페이징에서도 스와핑을 사용할 수 있다. 프로세스 전체가 스왑 아웃 / 인되는 것이 아닌 페이지 단위로 스왑 아웃 / 인된다. 이를 페이지 아웃 / 인이라 한다.
프로세스 전체가 적재될 필요가 없다는 말과 같다. 페이지 중 실행에 필요한 일부 페이지만을 메모리에 적재하고, 당장 실행에 필요하지 않은 페이지들은 보조기억장치에 남겨둘 수 있다. 이러한 방식으로 메모리보다 큰 프로세스를 실행할 수 있다.
페이지 테이블
프로세스가 메모리에 불연속적으로 배치되어 있다면 CPU 입장에서 이를 순차적으로 실행할 수 없다. 프로세스를 이루는 페이지가 어느 프레임에 적재되어 있는지 CPU가 모두 알기 어려워 다음 실행할 명령어의 위치를 찾기 힘들어진다.
이를 해결하기 위해 페이징 시스템은 프로세스가 비록 물리 주소에 불연속적으로 배치되더라도 논리 주소에는 연속적으로 배치되도록 페이지 테이블을 이용한다.
페이지 테이블은 페이지 번호와 프레임 번호를 짝지어 주는 일종의 이정표다. 페이지 테이블은 현재 어떤 페이지가 어떤 프레임에 할당되었는지를 알려준다. 이러한 방식으로 물리 주소상에서는 프로세스들이 분산되어 저장되어 있더라도 CPU 입장인 논리 주소는 연속적으로 보일 수 있다. 그렇기에 CPU는 논리 주소를 그저 순차적으로 실행하면 된다.
페이징은 외부 단편화 문제를 해결할 수 있지만, 내부 단편화라는 문제를 야기할 수 있다. 페이징은 프로세스의 논리 주소 공간을 페이지라는 일정한 크기 단위로 자른다고 했다. 그런데 모든 프로세스가 페이지 크기에 딱 맞게 잘리는 것은 아니다. 모든 프로세스 크기가 페이지의 배수는 아니다. 이때 메모리가 조금 남는데 이러한 메모리 낭비를 내부 단편화라고 한다.
그렇다면 페이지의 크기를 작게 하면 내부 단편화의 크기가 작아질 것으로 기대할 수 있다. 하지만, 페이지의 크기를 너무 작게하면 그만큼 페이지 테이블의 크기가 커져 차지하는 공간이 낭비된다. 그렇기에 내부 단편화를 적당히 방지하면서도 너무 크지 않은 페이지 테이블이 만들어지도록 페이지의 크기를 조정하는 것이 중요하다.
프로세스마다 각자의 페이지 테이블을 가지고 있고 각 프로세스의 페이지 테이블들은 메모리에 적재되어 있다. CPU 내의 페이지 테이블 베이스 레지스터(PTBR)는 각 프로세스의 페이지 테이블이 적재된 주소를 가리킨다. 각 프로세스들의 페이지 테이블 정보들은 각 프로세스의 PCB에 기록된다. 그리고 문맥 교환이 일어날 때 다른 레지스터와 마찬가지로 함께 변경된다.
페이지 테이블을 메모리에 두면 문제가 있다. 메모리에 있는 페이지 테이블을 보기 위해 한 번, 그렇게 알게 된 프레임에 접근하기 위해 한 번, 총 두 번의 메모리 접근이 필요해 두 배로 시간이 든다는 것이다.
이러한 문제를 해결하기 위해 CPU 곁에 TLB( Translation Lookaside Buffer)라는 페이지 테이블의 캐시 메모리를 둔다. TLB는 페이지 테이블의 일부 내용을 저장하고 참조 지역성에 근거해 최근 사용된 페이지 위주로 저장한다.
CPU가 발생한 논리 주소에 대한 페이지 번호가 TLB에 있을 경우 이를 TLB 히트라 한다. 이 경우 페이지가 적재된 프레임을 알기 위해 메모리에 접근할 필요가 없다. 하지만 페이지 번호가 TLB에 없을 경우 페이지가 적재된 프레임을 알기 위해 메모리 내의 페이지 테이블에 접근하는 수밖에 없다 이를 TLB 미스라 한다.
페이징에서의 주소 변환
하나의 페이지 혹은 프레임은 여러 주소를 포괄한다. 그렇기에 특정 주소에 접근하려면 어떤 페이지 혹은 프레임에 접근하고 싶은지, 접근하려는 주소가 그 페이지 혹은 프레임으로부터 얼마나 떨어져 있는지 알아야 한다.
그렇기에 페이징 시스템에서 모든 논리 주소가 기본적으로 페이지 번호와 변위를 가진다. 페이지 번호는 말 그대로 접근하고자 하는 페이지 번호다. 페이지 테이블에서 이 번호를 통해 페이지가 어떤 프레임에 할당되었는지를 알 수 있다. 변위는 접근하려는 주소가 프레임의 시작 번지로부터 얼마큼 떨어졌는지 알기 위한 정보다. 즉, 논리 주소 <페이지 번호, 변위>는 물리 주소 <프레임 번호, 변위>로 변환된다.
페이지 테이블 엔트리
페이지 테이블의 각 엔트리, 즉 페이지 테이블의 각각의 행들을 페이지 테이블 엔트리라 한다. 페이지 테이블 엔트리에 담기는 정보로는 페이지 번호와 프레임 번호뿐만 아니라 대표적으로 유효 비트, 보호 비트, 참조 비트, 수정 비트를 포함한다.
유효 비트(valid bit)는 현재 해당 페이지에 접근 가능한지 알려줍니다. 일반적으로 프로세스를 이루는 모든 페이지가 메모리에 있지 않고 일부 페이지는 보조기억장치에 있는 경우가 많다. 유효 비트는 현재 페이지가 메모리에 적재되어 있다면 1, 페이지가 메모리에 적재되어 있지 않다면 0이 된다. 만일 CPU가 유효 비트가 0인 페이지로 접근하려 하면 페이지 폴트(page fault)라는 예외가 발생한다. 페이지 폴트는 하드웨어 인터럽트를 처리하는 과정과 유사하다.
보호 비트(protection bit)는 페이지 보호 기능을 위해 존재하는 비트다. 해당 페이지가 읽고 쓰기가 모두 가능한지 혹은 읽기만 가능한지를 알 수 있다. 1인 경우 읽고 쓰기가 모두 가능하고 0인 경우 읽기만 가능하다. 앞에서 설명한 코드 영역 같은 읽기 전용 구간을 보호하는 데 사용한다. 더 구체적으로 읽기를 나타내는 r, 쓰기를 나타내는 w, 실행을 나타내는 x의 조합으로 1인 경우 가능하고 0인 경우 불가능하다는 것이다. 111은 읽기, 쓰기, 실행 모두 가능하다.
참조 비트(reference bit)는 CPU가 해당 페이지에 접근한 적이 있는지를 나타낸다. 적재 이후 읽거나 쓴 페이지는 참조 비트가 1로 한 번도 읽거나 쓴 적이 없는 페이지는 0으로 유지된다.
수정 비트(modifired bit)는 해당 페이지에 데이터를 쓴 적이 있는지 없는지 수정 여부를 알려준다. 더티 비트라고도 부른다. 1이면 변경된 적이 0이면 변경된 적이 없는 페이지다. 수정 비트는 페이지가 메모리에서 사라질 때 보조기억장치에 쓰기 작업을 해야 하는지 필요가 없는지 판단하기 위해 존재한다. 수정된 내용이 없는 경우 보조기억장치에 저장된 값과 서로 같기에 덮어쓰기만 하면 된다.
페이징의 이점 - 쓰기 시 복사
페이징은 외부 단편화를 해결한다는 점 말고도 프로세스 간에 페이즈를 공유할 수 있다는 이점이 있다. 이러한 사례로 공유 라이브러리 등 다양하지만, 대표적인 예시로 쓰기 시 복사가 있다.
앞에서 프로세스를 fork 하여 동일한 모든 자원을 복제한 프로세스가 같이 메모리에 적재된다 했다. 하지만 프로세스 간에 기본적으로 자원을 공유하지 않기에 서로 다른 메모리 공간에 적재된다. 즉 각 프로세스의 페이지 테이블은 자신의 고유한 페이지가 할당된 프레임을 가리키며 불필요한 메모리 낭비를 야기한다.
그러나 쓰기 시 복사에서는 부모 프로세스와 동일한 자식 프로세스가 생성되면 자식 프로세스로 하여금 부모 프로세스와 동일한 프레임을 가리킨다. 페이지 테이블만 각자 가지는 것이다. 그러나 프로세스 간에 자원을 공유하지 않는다 하였는데 그러면 페이지에 쓰기 작업을 하면 어떻게 될까? 바로 페이지에 쓰기 작업을 하면 그 순간 해당 페이지만 별도의 공간으로 복제되고 각 프로세스는 자신의 고유한 페이지가 할당된 페이지를 가리키게 된다. 이를 쓰기 시 복사라 하며 프로세스 생성 시간을 줄이고 메모리 공간 절약이 가능케 한다.
계층적 페이징
페이지 테이블의 크기는 생각보다 작지 않다. 프로세스의 크기가 커지면 자연히 프로세스 테이블의 크기도 커지기 때문에 프로세스를 이루는 모든 페이지 테이블 엔트리를 메모리에 두는 것은 메모리 낭비다. 이에 계층적 페이징(hierarchical paging)을 통해 해결할 수 있다.
계층적 페이징은 페이지 테이블을 페이징 하여 여러 단계의 페이지를 두는 방식이다. 여러 단계의 페이지를 둔다는 점에서 다단계 페이지 테이블 기법이라고도 부른다. 프로세스의 페이지 테이블을 여러 개의 페이지로 자르고, 바깥쪽에 페이지 테이블을 하나 더 두어 잘린 페이지 테이블의 페이지들을 가리키게 하는 방식이다.
이렇게 계층적으로 구성하면 모든 페이지 테이블을 항상 메모리에 유지할 필요가 없다. 페이지 테이블들 중 몇 개는 보조기억장치에 있어도 되며, 추후 참조해야 할 때 메모리에 적재하면 된다.
또한 CPU가 발생하는 논리 주소도 달라진다. <바깥 페이지 번호, 안쪽 페이지 번호, 변위>와 같이 이루어진다. 바깥 페이지 번호에 해당하는 항목은 CPU와 근접한 곳에 페이지 테이블 엔트리를 가리키고, 안쪽 페이지 번호는 첫 번째 페이지 테이블 바깥에 위치한 두 번째 페이지 테이블, 즉 페이지 테이블의 페이지 번호를 가리킨다.
바깥 페이지 번호를 통해 페이지 테이블의 페이지 찾은 후 페이지 테이블의 페이지를 통해 프레임 번호를 찾고 변위를 더함으로 물리 주소를 얻는다.
페이지 테이블 계층은 세 개, 네 개 그 이상으로도 구성 가능하다. 하지만 늘어날수록 페이지 폴트가 발생했을 경우 메모리 참조 횟수가 많아지므로 마냥 좋다고 볼 수 없다.
페이지 교체와 프레임 할당
요구 페이징
프로세스를 메모리에 적재할 때 처음부터 모든 페이지를 적재하지 않고 필요한 페이지만을 메모리에 적재하는 기법을 요구 페이징이라 한다.
참고로 아무런 페이지도 메모리에 적재하지 않은 채 무작정 실행부터 할 수 있다. 이 경우 실행하는 순간부터 페이지 폴트가 계속하여 발생하고 어느 정도 적재된 후 빈도가 떨어진다. 이를 순수 요구 페이징 기법이라 한다.
요구 페이징 시스템이 안정적으로 돌아가려면 페이지 교체와 프레임 할당 문제를 해결해야 한다.
요구 페이징 기법으로 페이지들을 적재하다 보면 언젠가 메모리가 가득 차게 된다. 이때 당장 실행에 필요한 페이지를 적재하기 위해 메모리에 적재된 페이지를 보조기억장치로 보내야 한다. 이때 어느 페이지를 보내는 것이 최선일까? 이를 결정하는 방법을 페이지 교체 알고리즘이라 한다.
페이지 교체 알고리즘
좋은 페이지 교체 알고리즘은 페이지 폴트를 가장 적게 일으키는 알고리즘이다. 페이즈 폴트가 일어나면 보조기억장치로부터 필요한 페이지를 가져와야 하기에 메모리로부터 가져오는 것보단 느려지기 때문이다.
페이지 교체 알고리즘을 이해하기 위해서 페이지 폴트 횟수를 알아야 하는데 이는 페이지 참조열을 통해 알 수 있다. 페이지 참조열은 CPU가 참조하는 페이지들 중 연속된 페이지를 생략한 페이지열을 의미한다. 연속된 페이지를 생략하는 이유는 중복된 페이지를 참조하는 행위는 페이지 폴트를 발생시키지 않기 때문이다. ex) 2223553337 -> 23537
- FIFO 페이지 교체 알고리즘
First-In First-Out Page Replacement Algorithm은 이름 그대로 메모리에 가장 먼저 올라온 페이지부터 내쫓는 방식이다. 프로세스가 사용할 수 있는 프레임이 세 개 있다 가정하고 페이지 참조열이 다음과 같다고 가정하자. 2313523423, 이때 5,2,3,4 순으로 페이지 폴트가 총 네 번 발생한다. 이 알고리즘은 아이디어와 구현이 간단하지만 마냥 좋지는 않다.
+ 이를 보완하기 위해 2차 기회 페이지 교체 알고리즘이 있다. 이는 가장 오래 머물렀던 페이지를 대상으로 내보낼 페이지를 선별하는 방식이다.
- 최적 페이지 교체 알고리즘
최적 페이지 교체 알고리즘은 CPU에 의해 참조되는 횟수를 고려하는 페이지 교체 알고리즘이다. 보조기억장치로 보내야 할 페이지는 앞으로 사용 빈도가 가장 낮은 페이지이므로, 앞으로의 사용빈도가 가장 낮은 페이지를 교체하는 알고리즘을 페이지 교체 알고리즘을 삼는 것이 가장 합리적이다. 이 알고리즘은 가장 낮은 페이지 폴트율을 보장하는 알고리즘이다. 타 페이지 교체 알고리즘에 비해 페이지 폴트 발생 빈도가 가장 낮다. 그러나, 앞으로 오랫동안 사용되지 않을 페이지를 예측하기란 어려워 실제 구현이 어렵다. 그렇기에 그 자체를 운영체제에서 사용하기보다는, 주로 다른 페이지 교체 알고리즘의 이론상 성능을 평가하기 위한 목적으로 사용된다.
- LRU 페이지 교체 알고리즘
가장 오랫동안 사용되지 않을 페이지를 교체하는 알고리즘은 구현하기 어렵지만 가장 오랫동안 사용되지 않은 페이지를 교체하는 알고리즘은 구현이 가능하다. 이 알고리즘이 LRU 페이지 교체 알고리즘이다.
페이지마다 마지막으로 사용한 시간을 토대로 최근에 가장 사용이 적었던 페이지를 교체한다.
스래싱과 프레임 할당
페이지 폴트가 자주 발생하는 이유에 나쁜 페이지 교체 알고리즘만이 이유는 아니다. 프로세스가 사용할 수 있는 프레임 수가 적어도 페이지 폴트는 자주 발생한다. 반대로 프로세스가 사용할 수 있는 프레임 수가 많으면 일반적으로 페이지 폴트 빈도는 감소한다.
프레임이 부족하면 CPU는 쉴 새 없이 프로세스를 실행해야 컴퓨터의 생산성도 올라가는데 페이지 교체에 너무 많은 시간을 쏟게 되어 결과적으로 CPU의 이용률도 떨어진다. 이처럼 프로세스가 실제 실행되는 시간보다 페이징에 더 많은 시간을 소요하여 성능이 저해되는 문제를 스래싱이라 한다.

스래싱을 그래프로 표현하면 위과 같다. 세로축인 CPU 이용률을 통해 CPU의 활용 정도를 알 수 있고 가로 축인 멀티프로그래밍의 정도를 통해 메모리에 올라와 있는 프로세스의 수를 알 수 있다. 메모리에서 동시에 실행되는 프로세스의 수를 멀티프로그래밍의 정도라 한다.
이 그래프는 프로세스의 수를 늘린다 해서 CPU의 이용률이 그에 비례해서 증가하는 것이 아님을 나타낸다. 필요 이상으로 늘리면 각 프로세스들이 사용할 수 있는 프레임 수가 적어지기 때문에 페이지 폴트가 지나치게 빈번히 발생하여 CPU 이용률이 떨어져 전체 성능이 저해된다.
스래싱이 발생하는 근본적인 원인은 각 프로세스가 필요로 하는 최소한의 프레임 수가 보장되지 않았기 때문이다. 그렇기에 운영체제는 각 프로세스들이 무리 없이 실행하기 위한 최소한의 프레임 수를 파악하고 프로세스들에 적절한 수만큼 프레임을 할당해 줄 수 있어야 한다.
가장 단순한 형태의 프레임 할당 방식으로는 균등하게 프레임을 제공하는 균등 할당이 있다. 프로세스들의 크기는 각기 다르기에 동일한 프레임 개수를 할당하는 것은 비합리적이기에 권장하지 않는다. 이에 프로세스의 크기가 크면 프레임을 많이 할당하고 프로세스 크기가 작으면 프레임을 적게 나누는 방식을 비례 할당이라 한다. 위 두 가지 방식은 프로세스의 실행 과정을 고려하지 않고 단순 프로세스와 물리 메모리의 크기만 고려하기에 정적 할당 방식이라고도 한다.
비례 할당 또한 완벽하진 않다. 막상 실행해 보면 프로세스 크기가 클지라도 프레임을 많은 프레임을 필요로 하지 않는 경우도 있고 이 반대의 경우도 있기에 결국 실행해 봐야 아는 경우가 많다. 그렇기에 실행 과정에서 배분할 프레임을 결정하는 방식으로 크게 작업 집합 모델과 페이지 폴트 빈도를 사용하는 방식이 있다. 위 두 방식은 프로세스의 실행 경과를 보고 할당할 프레임 수를 정하기에 동적 할당 방식이라고도 한다.
스래싱이 발생하는 이유는 빈번한 페이지 교체 때문이다. 그렇기에 작업 집합 모델 기반 프레임 할당 방식은 프로세스가 일정 기간 동안 참조한 페이지 집합을 기억하여 빈번한 페이지 교체를 방지하는 것이다.
CPU가 메모리를 참조할 때 참조 지역성의 원리에 의거해 주로 비슷한 구역을 집중적으로 참조한다. 그렇다면 CPU가 특정 시간 동안 주로 참조한 페이지 개수만큼만 프레임을 할당하면 페이지 교체는 빈번하게 발생하지 않을 것이다.
실행 중인 프로세스가 일정 시간 동안 참조한 페이지의 집합을 작업 집합이라 한다. CPU가 과거에 주로 참조한 페이지를 작업 집합에 포함한다면 운영체제는 작업 집합의 크기만큼만 프레임을 할당해 주면 된다.
페이지 폴트 빈도를 기반으로 한 프레임 할당은 다음 두 개의 가정에 생겨난 것이다,
- 페이지 폴트율이 너무 높으면 그 프로세스는 너무 적은 프레임을 갖고 있다.
- 페이지 폴트율이 너무 낮으면 그 프로세스는 너무 많은 프레임을 갖고 있다.
어찌 보면 당연한 말이다.
다음 그래프에서 가로축은 한 프로세스에 할당된 프레임 수, 세로축은 페이지 폴트 비율을 나타낸다.
여기에 임의로 페이지 폴트율 상한선과 하한선을 긋겠다.

상한선 보다 높아지면 프레임 수가 적다 판단하여 더 주면 되고 하한선보다 낮아지면 프레임이 너무 많기에 회수한다. 즉, 페이지 폴트 빈도 기반 프레임 할당 방식은 페이지 폴트율에 상한선과 하한선을 정해 이 범위 안에서만 프레임을 할당하는 방식이다.
'CS 공부 > 컴퓨터 구조, 운영체제' 카테고리의 다른 글
| 운영체제(7) - 파일 시스템 (0) | 2026.02.18 |
|---|---|
| 운영체제(5) - 교착 상태 (0) | 2026.02.16 |
| 운영체제(4) - 프로세스 동기화 (0) | 2026.02.15 |
| 운영체제(3) - CPU 스케줄링 (0) | 2026.02.14 |
| 운영체제(2) - 프로세스와 스레드 (0) | 2026.02.13 |