[운영체제] 8장 Memory Management Strategies

뱅커스 알고리즘은 중요한 개념임 꼭 알고 있기!

운영체제 – 컴퓨터 하드웨어(CPU, 메모리, I/O디바이스)를 잘 관리하여서 사용자가 사용할 원할 한 환경을 제공해 주는 것 -> 앞에서 배운 deadlock관련된 것들은 CPU관련된 것임

여기서 부터는 메모리를 관리하는 것을 배움 -> 하드웨어 속 과정은 사용자가 잘 알 수 없음

-> 운영체제의 지원으로 알지 못해도 구현이 가능함

ex. int, float와 같은 것들이 어느 메모리에 할당되는지 굳이 알 필요가 없음

 

Binding of Instructions and Data to Memory

프로세스를 수행하려면 명령어와 데이터가 메모리로 올라가서 수행을 해야 함

명령어는 크게 문제가 되지 않지만 데이터주소가 언제 바인딩 되는지 3가지(언제 메모리에 할당되는지)

Compile time

• 컴파일 시 데이터메모리 주소가 결정됨
• 컴퓨터를 사용하기 위해 하드웨어를 동작시키는 데 필요한 언어처리를 하는 시간

Load time

• 로드 시 데이터메모리 주소가 결정됨
• load(CPU에서 메모리를 가져오는 것)
• 프로그램은 하드디스크나 SSD와 같은 스토리지에 저장되어 있음
• 스토리지 메모리(외부기억장치)에 있는 정보들이 RAM(내부기억장치)에 올리는 작업(Load, 프로그램 수행을 위함)

Execution time

• 실행 시 메모리 주소를 결정
• 메모리에 모두 올려두고 실행 시에 메모리주소가 결정됨

 

순서 : Compile -> Load -> Execution

 

 

Compile time 방식 예시

-> 주소 메모리 지정이 필요함(특정 메모리에서 사용함) - 컴파일과 메모리에 올라갔을 때 메모리 주소가 동일함

-> 현재 컴퓨터에는 어려움이 있음 – 지정된 곳에만 올릴 수 있다고 하면 비효율적임(비어있을 경우가 많음, 현재 사용x)

장점

컴파일 쉬움, 로드도 쉬움, 실행 시에도 계산이 없음(오버헤드 없음)

단점

메모리 주소가 항상 지정되어 여러 프로그램을 미리 올려서 사용하는 멀티프로그래밍에는 부적절함

 

 

Load time 방식 예시

-동적으로 메모리에 데이터주소를 바꾸며 올릴 수 있다

-메모리에 올릴 때 메모리 주소 값에 추가적인 연산이 필요함

장점

컴파일은 쉬움, 실행 시 오버헤드는 줄어듦

단점

로드할 때 많은 오버헤드가 발생, 프로그램이 크면 클수록 프로그램을 메모리에 올릴 때 시간이 오래 걸림.(=프로그램 실행 시 오래 걸림)

 

 

Execution time 방식 예시(현재 운영체제에서 많이 사용) - 컴파일까지는 로드와 동일

-메모리에 올려 졌을 때는 컴파일 주소 값이 바뀌지 않음(그대로 메모리에 저장됨) ->메모리에 올려두었다가 실행될 때 계산되어 정해짐

 

장점 - 컴파일은 쉬움, 로드 시 별도의 오버헤드도 없음

단점 - 실행을 할 때 항상 계산이 동반되어 오버헤드가 있음.

+연산 필요(연산을 하드웨어 로직에 포함시킴, CPU가 직접처리x -> 오버헤드가 줄어든다. => MMU-Memory Management Unit, 하드웨어 로직이 프로세스에 저장이 되어있음)

3가지 방식에도 Trade off(장단점 공존)가 존재

 

 

Memory Management 목적

-프로그래밍 할 때 쉽게 메모리를 할당하기 위함

-메모리를 효율적으로 사용하기 위함(리소스를 잘 분배, 오버헤드를 줄임)

-프로세스가 메모리를 독립적으로 사용할 수 있게 지원을 하기 위함

 

Memory Management 역사

Batch programming – 프로그램이 메모리에 오직 하나만 올라감(사실상 Memory Management가 필요 없었음)

Multiprogramming – 여러 사람이 한 컴퓨터를 두고 리소스를 사용함(이 때문에 Memory Management가 등장함)

 

Memory Management의 Issues

-사용자가 사용하기 편해야함

-메모리가 부족하지만 많은 프로세스가 동작했으면 좋겠음

-성능 고려

-여러 프로세스 간에 나누어 쓰는 것이 쉬웠으면 좋겠음

 

Memory Management의 방법 -> Virtual Memory (VM, Memory Management의 핵심 방법) - 메모리를 가상으로 쪼게어 사용하는 것(8, 9장으로 나누어 설명함)

메모리를 2가지 레벨로 나누어 생각함

>physical 레벨 – 컴퓨터 하드웨어에 물리적으로 나와 있는 주로(physical address)

>virtual(logical) 레벨 – 실제로 그곳에 저장되어 있진 않지만 저장되어 있다고 생각할 수 있는 것(프로그램이 내부에서 가상으로 사용하는 메모리 - VM)

-앞의 3가지(Compile time, Load time, Execution time)는 physical한 부분임

 

Virtual Memory (VM)

장점

사용이 편해짐(물리적인 부분을 고려하지 않아도 논리적인 부분에서 고려(접근이 됨)됨)

프로그램을 실행을 할 때 프로그램 전체가 사용되지 않음.

-> 더 큰 용량의 프로그램을 사용 가능(사용하지 않는 프로그램은 메모리에 올려두지 않음)

필요한 프로세스만 올려서 사용을 함

 

Virtual Memory (VM)설명 그림

virtual address에서 MMU를 통해서 실제 physical address에 접근을 함(실행타임과 유사)

 

 

Dynamic Loading

Dynamic Loading – 필요한 시점에 필요한 것들만 메모리에 올림

Loading – 실행하고자 하는 프로그램을 메모리에 올리는 것

 

 

Dynamic Linking

Dynamic Linking – 실행파일을 만들 때 모두 통합하여 linking하여 만들지 않고 각각이 사용될 때만 링크하여 사용하는 것(DLL-동적 링크 라이브러리, 윈도우에서 동적링킹을 할 때 사용되는 라이브러리 타입)

ex. C++에서 cout을 사용할 때 cout이 사용될 때 라이브러리 하나만 메모리에 올려서 실행될 때마다 메모리로 점프를 해서 수행을 하는 것

Linking(연결) - 컴파일하고 객체파일이 만들어지고 연결되어 만들어지는 것(다른 사람이 만들어 놓은 라이브러리도 함께 링킹함)

 

 

Overlays(예전에 많이 사용 현재는 사용x)

남아있는 공간보다 실행해야하는 용량이 더 큼 -> 프로그램이 실행되지 않음

프리 프로세싱을 진행을 하여 프로그램을 분할을 함 -> 실행을 할 때 필요한 부분만 주기억 장치 메모리에 올려서 실행을 할 수 있게 해주는 방식 -> 이때 분할된 각각의 부분을 세그먼트 또는 모듈이라고 불림

-> 주프로그램은 항상 주기억장치에 머물면서 필요한 세그먼트를 오버레이버퍼라는 기억장치에서 불러옴

이러한 오버레이 기법은 PC와 같이 상대적으로 용량이 작은 장치에서 용량이 큰 프로그램을 실행시킬 때 활용됨

 

Swapping(오버레이와 비슷, 두 개의 값을 맞교환해줌)

 

Swapping 예시

메인메모리에서 프로그램을 꽉 채워 수행중일 때 하드디스크나 SSD와 같은 스토리지에 저장되어 있는 프로그램을 실행시킬 때 실행되고 있는 프로그램을 내리고(swap out) 스토리지에 있는 프로그램을 올리는 것(swap in)

>>메모리에 있는 프로그램을 내렸다 올렸다 하는 행위의 반복이 있음으로 느림(context switch 시간이 많아진다.)

>VM과의 차이는 VM방식은 프로세스 단위로 프로그램을 올렸다 내렸다 하지 않는다. -> 더 작은 단위인 페이징 단위로 올렸다 내렸다 함

>>메모리에 올라와있는 하나의 프로세스와 하드디스크나 SSD와 같은 스토리지에 적재된 프로세스를 교체하는 방식임

 

Logical vs. Physical Address Space

VM에서 중요한 것은 주소가 2가지가 있다는 것임!!

>Logical address

 -프로그램 내부에서 사용하는 가상 주소

>Physical address

 -실제 메모리에 주소

>>이런 두 개의 메모리주소의 트랜스레이션은 명령어를 실행을 할 때 CPU에 있는 하드웨어 로직에서 트랜스레이션이 일어남

>>Logical address에서 Physical address로 트랜스레이션 하는 부분이 VM의 핵심

 

Logical Address 소스코드 예시

프로그램 안에서 사용되는 주소는 Logical address임

출력되는 주소는 Logical address이다.

 

 

Memory-Management Unit(MMU)

-Logical address에서 Physical address로 트랜스레이션하는 역할을 함.

 

트랜스레이션하는 과정 예시

Logical address가 Physical address로 연속적으로 배치되게 만들기 위해 Relocation(재배치)값을 설정해줌(여기서의 MMU는 +연산만 필요함)

>>이렇게 + 연산만을 이용하면 문제들이 발생(프로그램을 연속적으로 배치시킬 수밖에 없음)

-> 이렇게 순차적으로 배치하는 것을 보고 continuous allocation이라고 함

 

 

Continuous Allocation(연속적으로 할당을 함)

메모리에 새로운 프로세스가 할당이 되면 아래부터 채워나가는 방법

(내용 읽어보기)

 

Continuous Allocation 과정

 

Continuous Allocation

메모리에 프로세스가 아래서부터 순차적으로 할당됨(맨 위는 운영체제가 위치함)

중간에 있는 프로세스가 끝마쳐지게 되면 프로세스가 있던 메모리의 공간이 비어있게 됨

여기서 생기는 빈 공간(Hole or free partition) -> 빈 공간에 새로운 프로세스들이 적재되어 쌓임 -> 여기서 PPT그림 기준 프로세스 9번이 완료되어 빠져나가게 되고 다음프로세스가 빈 공간들 보단 남은 전체공간보단 작다면 어떻게 될까? -> 이 방법에서는 적재될 수 없음(실행되지 않는다) -> 이유는 어떠한 공간에도 들어갈 수 없기 때문이다.

 

 

Continuous Allocation 문제점

프로세스가 쌓이는 3가지 방법

• First-fit(최초적합) - 가장 첫 번째로 보이는 빈 공간에 적재시키는 것
• Best-fit(최적적합) - 빈 공간을 모두확인해보고 빈 공간이 가장 적게 남는 방향으로 적재를 시키는 것
• Worst-fit(최악적합) - 빈 공간 중 가장 많이 남아있는 공간에 적재를 시키는 것

 

 

Fragmentation

• External Fragmentation(외부단편화 문제) - 프로세스가 외부에서 들어왔는데 남은 빈 공간들 보다 용량이 커서 적재(할당)되지 못하는 상황
• Internal Fragmentation(내부단편화 문제) - 내부적으로 프로세스가 할당이 되었을 때 실제 프로세스가 사용하는 크기보다 크게(더 많이) 할당되어 내부적으로 공간이 낭비가 되는 상황

>>그러면 이렇게 사이즈가 큰 프로세스로 관리를 하지 말고 더 작은 단위를 만들어서 사용하면 되는 것 아닐까?

 

Paging(프로세스들을 더 작은 페이지 단위로 쪼게어 여기저기 적재를 시키는 것)

-> 빈 공간 각각의 크기가 작더라도 전체 남은 메모리 크기가 크다면 프로세스를 적재 가능

 

Paging 기법 예시

프로세스를 쪼게어 logical memory에서 사용하는 단위를 Page, physical memory에서 사용하는 단위를 Frame이라고 한다.

logical memory에서 page가 physical memory(실제메모리)의 어디 프레임에 위치하고 있는지 기록(page table에 기록함)해 놓기 위해 page mapping 작업을 거침

 

 

page 주소를 어떻게 physical memory로 Translation하는지 보여주는 그림

page주소가 physical memory에 어디에 위치하고 있나 저장하고 있는 page table이 프로세스 마다 존재함

-> p는 page번호를 의미, f는 frame번호를 의미함, d는 offset을 의미(시작 주소로부터 얼마만큼 떨어져 있는지를 나타냄, 사실상 변하지 않음)

 

page 주소를 어떻게 physical memory로 Translation

 

paging address를 변환하는 과정에 대한 예시

CPU주소 버스가 32bits로 4GB메모리에 대한 예시

-> PN(page number), FN(frame number)

 

paging 예시

 

Free Frames

운영체제가 Free Frames list(빈 프레임 목록)을 관리를 해서 새로운 프로세스가 들어오게 되면 빈 공간에 프로세스 page들을 적재시켜줌

 

 

page table 구현

어떻게 구현을 해야 하는 것인지

page table – 주소변환을 자료구조로 물리 메모리에 위치해 있음

접근하기 위해서 운영체제에서 2가지 레지스터 사용(연산)

Page-table base register (PTBR) - 메모리 내에서 page의 시작위치를 알려주는 레지스터

Page-table length register (PTLR) - page table의 크기를 저장하고 있는 레지스터

paging 기법의 메모리 접근 연산은 주소 변환을 위해 page table에 접근할 때 한번 일어나고 변환된 주소에서 실제 데이터에 접근할 때 한번 일어난다.

따라서 총 2번의 연산이 일어남

이에 따른 오버헤드를 줄이고 메모리에 접근 속도를 향상시키기 위해 TLB(하드웨어 캐시 메모리, 가격이 비싸고 크기가 작음) 사용

TLB(Translation Look-aside Buffers) – 빈번히 사용되는 page에 대한 주소변환정보만을 모아두다가 기록된 page 연산 요청이 들어오게 되면 바로 캐시메모리에 있는 주소변환정보를 불러다가 사용하기 위해 사용됨

page table이 생각보다 크기가 크기 때문에 CPU 구현을 통해 사용하지 않고 page table의 일부만을 MMU에 넣어서 CPU에 캐시메모리형태로 TLB라는 캐시메모리를 따로 두고 page table을 access함 -> 오버헤드를 줄이는 방안

 

Paging Hardware With TLB(캐시메모리) 그림

이러한 paging 기법을 사용하게 되면서 page table과 TLB(캐시메모리)를 관리해야하는 상태가 됨

page number가 들어옴 -> TLB 캐시메모리 안에서 프레임번호와 페이지번호를 비교 -> TLB안에 있다면 -> TLB hit됨 -> 그에 대한 프레임번호와 맞는 물리주소를 반환을 받아서 불러올 수 있음

->TLB에 hit가 되지 않는다면 -> TLB miss됨 -> page table로 가서 페이지번호와 프레임번호를 비교해가며 찾게 됨.

TLB 내에 page number와 frame number를 모두 가지고 있어야함.

일반적으로는 메모리의 주소를 입력받으면 데이터를 주는 것이 일반적이지만 TLB는 페이지번호를 입력하면 데이터가 매칭이 되어 팅겨져 나옴(일반적인 캐시메모리와 다름)

 

 

Associative Memory

Associative Memory – 위와 같은 메모리, 일반적인 메모리처럼 입력 값으로 주소 값을 넣는게 아닌 컨텐츠를 입력하게 되면 데이터가 튀어나오는 메모리

 

TLB(특별한 메모리)중요

 

TLB성질

• 시간적 지역성(Temporal locality) - 최근에 참조된 데이터가 또 참조될 확률이 높다고 판단하여 캐시메모리에서 가지고 있는 것
• 공간적 지역성(Spatial locality) - 어떠한 곳이 참조가 되었다면 그 주변의 것들이 참조될 확률이 높다고 생각하여 캐시메모리에 가지고 있는 것

TLB miss 발생 시 어떻게 처리를 하는지

CPU가 메모리를 참조하려고 접근했을 때 miss가 발생했다면(TLB에 없는 것) -> page table로 감 -> 누가 처리하느냐? x86(MMU HW)는 HW에서 처리를 함(지금 프로세스에서 어디 페이지 테이블에 있는지 CPU에서 알고 있기 때문에 찾아가서 처리함), 그리고 OS에서 처리하는 방법도 있지만 – CPU(CPU가 자기 자신에게 trap을 걸어 os에게 찾아보라고 함)가 처리를 안 하겠다면 OS가 처리해야함(이러면 오버헤드가 큼) -> 따라서 HW에서 처리를 함

 

TLB Management

OS가 처리하면 오버헤드가 크기 때문에 HW에서 처리함

 

Effective Access Time 계산 과정(알아둘 것)

-> 평균적인 메모리 접근시간에 대한 산출 방법

 

Memory Protection

자기 자신의 프로세스에서 access할 수 있는 메모리 영역이 존재하는데 이곳에서 벗어나 다른 영역에 접근하려는 것을 막아주는 것(이 과정에서 운영체제가 HW의 도움을 받아 막아주어야 함)

우리가 참조할 logical한 메모리 영역의 리밋 값이 범위보다 큰지 작은지를 판단해줌

->paging에서는 page 번호가 0부터 max 값이 존재함 -> page번호가 0부터 max까지 안에 존재하는지 판단을 함 -> but 다른 방식을 사용함

 

그 방식이 Valid (v) or Invalid (i)를 사용해서 표현하는 것

Valid (v) or Invalid (i) Bit In A Page Table 예시

Valid (v) or Invalid (i) 방식으로 한 비트를 더 추가해서 표현을 함

의문점 페이지 번호를 보고만 판단하면 될 것 같은데 굳이 한 비트를 추가하는 이유는? -> (9장에서 다룸)

간략 설명 -> 고정적인 상태가 있는 것이 아닌 page의 사용여부가 변화함

VM Management에서 paging 단위로 구성 이 때 데이터를 올라갔다 내려갔다 하는 경우에 메모리에 현재 올라와있지 않아 Invalid상태로 나옴

ex. pc카톡을 켤 때 업데이트 상황에서 page에서 앞부분이 로그인 시 사용하는 부분이라면 로그인시에만 사용되기 때문에 처음에만 사용되고 이후에는 사용하지 않는다.

앞으로 안 쓰일 page를 알아서 내보내는 것이 효율적이다.

최근에 사용된 것이 다음에도 많이 열릴 것으로 예상하고 판단을 해줌-> 9장에서 자세히 다룸

memory protection으로 위해서 사용된다고만 알고 있기

 

Page Table 구성

>Valid bit (V) - Valid (v) or Invalid (i) Bit

>Reference bit (R) - 메모리가 참조되는 안 되는지를 나타냄

>Modify bit (M) - 메모리가 변경이 되었는지 안 되었는지 나타냄

>Protection bits (Prot) - 2bits를 사용하여 해당 page가 읽기가 가능한지 쓰기가 가능한지 실행이 가능한지를 나태내어 줌

>Frame number (FN)

 

page Table이 실제로 메인메모리에 가져다 놓기에 크기가 큼 따라서 등장한 기법 3가지

Page Table Structure

• Hierarchical Paging(계층적, 현재 사용되고 있는 기법)
• Hashed Page Tables
• Inverted Page Tables

 

 

(49page)

Hierarchical Paging 예시

 

 

 

(50page)

Hierarchical(계층적) Paging 예시

4KB(4096B, entry 사이즈를 byte라고 하면) 크기의 page에 32bits 명령어 기계가 있다고 하자

page를 다시 두 단계로 나눔 (page number-20bits, page offset-12bits)

-> 앞부분은 모두 valid이고 뒷부분은 모두 invalid이다. 이렇게 표현해야한다는 단점이 있음.

왜 멀쩡한 테이블을 나누는 것인가?

온전히 20bits로 테이블에 접근하게 된다면 엔트리 크기가 4byte이므로 2^2 * 2^20 해서

페이지 테이블 크기가 2^22이 되어 엄청 커지게 됨 -> 이렇게 큰 크기를 메모리에 연속적으로 할당하는 것은 부담이 됨. 또 페이지 테이블에서 사용하지 않는 공간 역시 엔트리로 가지고 있어야하기 때문에 2^22모두 공간으로 가지고 있게 되면 공간낭비가 심함

-> 따라서 20 bits를 두 개로 나누어 10bits씩 두 개의 계층 테이블 구조로 사용함

 

Hierarchical Paging 그림예시

두 단계로 나누어 메모리에 저장되어 있는 데이터를 불러오는 방식

outer-page table과 inner-table(page of page table)로 나누어서 outer-page table에서 들어오는 logical한 메모리 주소를 다시 inner-table로 해서 메모리에 접근을 함

이 방법의 장점 - outer-page table을 두게 되면 이것(outer-page table)만을 관리해주면 됨 -> 실제 관리해줄 page table이 줄어듦(보다 효율적임)

 

이러한 계층적 테이블 구조는 32bits 테이블 구조에서 가장 적함

Address-Translation Scheme

 

address space가 더 커질 경우 더 많은 단계로 나누어 사용을 함 -> Multi-level Page Tables

64bits 환경일 때는 3개로 나누어 관리를 함 -> 이것은 예전에 알파라는 CPU에 도입이 되어 사용을 한 시스템임

 

 

Hashed Page Tables

주소 공간이 32bits보다 큰 경우 사용이 됨

hash table -> key와 value로 구성이 된 테이블 구성을 가짐

해시태그와 같이 #을 붙여서 표시해주는 것처럼 해시태그를 통해서 검색이 가능(mapping을 해주는 것)

-> 논리주소의 해시 값을 이용해서 바로 물리주소를 가리키는 것

나누기 1000을 하여 1000번지까지 사용을 함(몫)

 

 

Hashed Page Table 그림 예시

논리주소 값이 들어오면 1000으로 나누는 등의 행동(해시함수)을 해서 해시 값으로 나타냄

해시 값으로 해시 테이블에 항목을 찾아다가 가상 페이지 번호와 비교를 해서 매치가 되면 해당항목의 필드(프레임번호)를 사용을 해서 물리적 주소로 변화를 받고 매치를 해줌

 

Hashed Page Tables의 장점

해시 테이블을 통해서 주소 값들을 뭉쳐놓는다. -> 해시 테이블을 뭉쳐놓기 때문에 페이지 테이블이 줄어든다.

 

 

 

Inverted Page Table (역 페이지 테이블)

프로세스 마다 page table을 가지고 있어야하는데 이러면 공간낭비(가장 큰 문제)가 생김

이러한 방법을 역으로 만들어봄

페이지 테이블이 딱 하나만 존재하고 엔트리가 프로세스 기준이 아닌 물리메모리의 프레임 개수만큼 존재하도록 만들어봄

 

Inverted Page Table 그림 예시

따라서 페이지 테이블은 어떤 페이지의 테이블인지 알 수 있는 PID와 몇 번째 페이지인지 P(page number)가 저장이 됨

또한 반대로 물리 메모리에 어느 위치에 저장이 되었는지를 프레임의 인덱스 정보로 알 수 있도록 만들어 주는 것 -> 주소 변환을 해야 할 경우 CPU는 논리주소의 PID와 P에 맞는 엔트리를 찾기 위해서 페이지 테이블을 모두 검색을 하고 찾았다면 인덱스 정보를 가지고 프레임 정보를 알아내어서 PID와 P를 F(Frame number)로 바꾸어 주는 방식

-> 이 기법은 공간적이 이점은 있지만

처음 인덱스로 접근하는 것이 아닌 모든 테이블의 엔트리를 검색(병렬적 검색이 필요)해야하기 때문에 오버헤드가 많이 일어나기 때문에 실제로 사용x

 

Shared Pages

메모리에서 관리하는 페이지 테이블의 크기가 너무 크기 때문에 이를 줄이는 방법 3가지를 배움

현재는 Hierarchical Paging 기법이 전체 관리할 page table을 줄여줌 -> 이것을 많이 사용

또 다른 이야기 Shared Pages 기법

 

Shared Pages 예시

3개의 프로세스가 모두가 같은 에디터 프로그램을 사용하게 된다면 코드 세그먼트는 같고 사용하는 데이터만 다르다

-> 따라서 공통적으로 사용하는 프로세스의 요소들을 페이징 기법을 통해서 shared page로 묶어서 사용

메모리를 쉽게 공유할 수 있음

 

Advantages of Paging

물리적으로 사용하기가 쉽다

외부 단편화가 거의 없다

잘 사용하지 않는 메모리의 내용을 하드디스크로 잠시 내려 보내서 훨씬 더 VM를 쉽게 할 수 있음

메모리 프로텍션도 할 수 있음

페이지 공유도 쉬움

실제로도 많이 사용됨

 

Disadvantages of Paging -> 거의 극복이 됨

내부단편화 문제가 있다.(피할 수 없는 것임, but 그렇게 크기가 크지는 않음)

메모리 참조 오버헤드가 큼 -> TLB(캐시)를 통해 극복함

페이지 테이블의 크기가 크다 -> 3가지 기법으로 극복함

->페이지 내에서도 공간의 낭비가 날 수 도 있음 -> 그래서 Segmentation등장

 

Paging 기법 -> 프로세스를 일정 크기인 페이지 단위로 잘라서 메모리에 적재시키는 것

-> 정확하게 일정한 간격으로 자르는 단위를 말함

-> 결국에는 페이징 기법 역시 프로세스를 적재하는데 특정 크기만큼 블록단위로 관리를 해주는 기법임 -> 페이지에 저장되는 데이터의 크기가 페이지보다 작은 것이 존재할 수 있음

-> 이렇게 되면 공간의 낭비가 일어나게 됨. -> 이 때문에 Segmentation 기법이 등장함

-> 페이징 기법처럼 물리적으로 동일한 단위로 자르지말고 의미있는 단위로 자르자는 것에서 Segmentation이 등장함.

 

Segmentation(논리적 내용단위, 의미 있는 단위로 쪼게 보자, 카테고리 별 용기저장)

의미있는 단위 종류

• Main program
• Procedure
• Function
• Method -> 자바에서 객체지향언어에서 사용하는 함수와 같은 의미임
• Object
• Local variables, Global variables
• Common block
• Stack
• Symbol table
• Arrays

>>이러한 단위로 잘라서 적재를 시켜보자!

 

Segmentation(논리적 내용의 단위로 자름, 크기가 항상 같진 않음) 구성

 

Logical View of Segmentation

-> 기능별로 잘라서 관리를 함

-> 사실 하나의 프로세스가 동작을 하려면 기본적인 코드, 데이터, 스택 이렇게 3가지 세그먼트는 항상 가지고 있음.

-> Segmentation은 논리적 단위로 의미가 같은 것들로 자르는 것임

 

Segmentation Architecture

segment-number, offset로 구성이 되어있음

Segment table -> 물리적 주소에 어디에 저장되는지 알려줌

 

Segmentation Hardware

-> Segmentation table은 paging 기법과 유사하게 구성이 되어있음

-> MMU 내의 재배치레지스터를 이용해서 논리주소를 물리주소로 바꾸어줌

-> MMU는 세크먼테이션 테이블로 CPU에서 할당된 논리 주소에서 해당하는 물리주소를 찾고 테이블을 통해서 주소를 변환해서 메모리에 저장되어있는 데이터를 가져옴

-> 이 방법을 이용하면 CPU프로세스가 어떤 연속된 메모리 공간에 위치하고 있다고 생각할 수 있음

 

Segmentation(가변요소) 예시 그림

-> 페이징 기법의 내부단편화 문제를 해결할 수 있음

왜 해결 할 수 있나? 페이징 기법은 정해진 크기만큼의 잘라서 데이터를 저장을 하기 때문에 내부에서 충분히 공간 낭비가 일어날 수 있음 -> 그러나 Segmentation과 같은 가변 크기로 저장을 하게 된다면 낭비되는 공간이 사라지게 된다.

-> but 프로세스 단위로 메모리 할당해준 것과 유사 -> 외부 단편화 문제가 발생

-> 새로운 Segmentation이 들어왔는데 어디에 적재되어야 할지 찾아야 하는데 그림과 같이 연속되게 관리를 하게 되면 들어갈 공간이 충분히 있는데 못 들어가는 상황이 발생함.

-> Segmentation만을 가지고는 문제가 발생함

>>Segmentation 기법과 페이징 기법을 혼합해서 사용함

 

 

 

 

Paging vs. Segmentation

Hybrid approaches(Paging, Segmentation를 혼용한 것)

-> Paged segments 또는 Segmentation with Paging라고 불림

-> 어떻게 혼합하는게 좋을까? Segment로 먼저 구분 후 page로 구분하면 효율성이 높음

-> 예를 들어 인텔 펜티엄 프로세스에서는 코드 세그먼트, 데이터 세그먼트, 스택 세그먼트, 엑스트라 세그먼트 와같이 4개로 분할을 하고 그것들을 다시 페이지로 관리하는 방식을 사용함

 

Segmentation with Paging – Intel Pentium

-> offset이 상당히 큼

그림 위쪽이 Segmentation부분, 아래가 페이징 부분임

-> 세그먼트 번호를 인텔 펜티엄 프로세스에서는 selector라고 부름, 세그먼트 테이블을 descriptor table이라고 부름 -> 세그먼트 테이블에 들어가면 세그먼트 시작위치가 나옴

-> 시작위치에 offset을 더해주면 물리적 주소처럼 가상의 주소가 나오게 된다.(이것이 페이징에서 사용하는 logical address가 됨)

linear address의 구성 – 앞부분은 페이지 번호가 나와 있고 뒷부분은 페이지 내에서의 offset이 나와 있음

그런데 이 페이지 테이블도 상당히 크기 때문에 계층적 페이지 테이블 관리 방법을 사용함

-> page directory(outer table, 페이지 테이블이 나옴), page table(inner table, 페이지 프레임이 나옴) -> 더불어 프레임 번호와 offset을 더하면 물리주소가 나옴