운영체제의 기초 - 15. Segmentation and Paging 1

Segmentation

프로세스가 메모리를 할당 받고 동적으로 수행하면서 메모리와 관련해서 

여러가지 interaction(상호작용)을 하는데 이때 효율성을 높이고 부작용을 최소화 하는 기법들에 대해서 공부할 예정

 

multiprogrammed batch monitor 시절

동시에 Active한 Job들이 여러개 메인메모리에 존재할 수 있었음

메인 메모리 한쪽 끝에는 core resident한 시스템 S/W가 있었는데 그것이 Batch Monitor임

나머지 영역은 User process를 위해서 사용되는 것

그림을 보면 지난 시간에 공부했던 Dynamic Allocation이 생가나죠?

이런 형태로 Process를 수행시키면 fragmentation(단편화) 문제가 발생한다

multiprogrammed batch monitor 특징

- User Process가 하나의 메모리 segment를 할당받음

linker 시간에 배웠는데 메모리에는 data section, text section 그리고 이것이 수행되려면 stack 과 heap 공간이 필요하다는 것을 배웠음

그런데 이와 같은 방식으로 하면 (data section, text section, stack 과 heap) 전체가 하나의 메모리 segment에 매핑이 되는 문제가 발생함

- linker가 Process의 execute file을 section 별로 나눈 이유가 있음 

  속성이 다르기 때문! (Read-only냐? Read/Write 할 수 있냐? ) 두가지 측면에서 메모리 section들을 달리 봐야할 필요가 있다는 것임

  text section은 code section이기 때문에 수행되에 modify 할 필요가 없음 (Read only section임)

  Data section은 당연히 읽을 수도 있고 쓸 수도 있음

  Stack / heap도 Read/write가 되는 section임

한 User Process의 Memory Section들이 하나의 Memory Segment를 할당받을 때 발생하는 문제점

1. 두 User Process가 동일한 코드(Text Section)을 공유하기 힘들다.

2. 각 Memory Section들에게 다른 Read/Write 권한을 설정하기 힘들다.

이것이 과거 multiprogrammed batch monitor 시절의 큰 한계였음

사람들이 이런점에 주목을 했음

- 속성이 다른 Section들에게 다른 Memory Segment 할당해주자

- 이것이 memory segmentation이라고 부름

Memory Segmentation은 과거의 제한점에 대한 해결책임

이것은 새로운 문제가 생기게 됨

- Process Section당 한 segment를 할당하게 되면 address 매핑에 굉장히 쉬워짐

과거에 이렇게 했을 때

싱글 세그먼트 프로세스 했을 때 메모리 address translation어떻게 했나요?

두개의 register를 가지고 했음 (base register와 bound register)

base register를 가지고 relocation을 했음

그런데 문제는 각 메모리 segment들이 존재하기 때문에

각 segment마다 별도의 base register와 bound register를 별도로 유지해야할 필요가 생김

그래서 Memory Segmentation을 하게 되면 address translation 로직이 복잡해 짐

각 세그먼트마다 별도의 베이스레지스터를 할당하려면 H/W 적으로 어떻게 구현할까? (2가지)

1. 프로세스당 4개의 segment만 지원을 해주겠다. 그래서 고정을 시켜주는 것

   code segment를 시작할 때는 code segment의 base address를 어떤 특정 register로 매핑하고

   data segment도 base address도 특정 register로 매핑하는 것

   이와 같이 H/W적으로 segment base process offset 방식으로 addressing을 제공해 주면 segment를 할 수 있음

   ex) 과거 intel Processor임 segment address register를 별도로 가지고 있음

2. 조금더 일반적인 형태가 있음

    별도의 레지스터를 할당하지 않고 메인 메모리에 segment의 base/bound register paired를 테이블 형태로 기록하는 것

    

이와 같이 multiple segment를 지원하고 segment의 base address를 table로 만들어서 메인메모리에 저장한 다음에

address translation을 하게 되면 약간 address translation이 복잡하게 됩니다.

address translation 과정

이제 CPU가 address bus로 address를 날리게 되면 바로 Physical memory address로 가는 것이 아니라 그 address의 일정 정보를 얻어 메인메모리에 있는 segment table에서 해당 entry를 찾아 lookup을 한다음에 base address값을 얻어 add한 다음에 bound보다 작은 값인가를 체크하는 그런 형태로 다소 복잡한 address translation을 해야 합니다.

여기서 결론은 free lunch는 없다 싱글세그먼트의 문제를 해결하기 위한 multiple segment는 좀더 복잡한 memory management unit과 복잡한 operation이 필요하다.

CPU가 생성하는 address

MMU가 변환시키는 address

궁극적으로 이것이 Physical memory의 address가 됨

*MMU (Memory Management Unit): CPU가 Physical Memory에 접근하는 것을 관리하는 하드웨어 장치

경우에 따라 logical address를 virtual address라고도 부름

이제 MMU의 기능이 중요하게 됨

MMU가 table lookup을 하고 base register 값을 더한 다음에 compare(비교)하는 operation

MMU는 table lookup하기 위해서 메인메모리를 접근할 수 있는 기능도 추가되어야 함

* address translation: CPU에서 만든 주소를 물리메모리가 이해할 수 있는 주소로 변환하는 작업

logical address는 CPU가 만들어내는 address 일뿐만 아니라 프로그래머(컴파일러와 링커)가 보는 address임 

그러나 요즘은 프로그래머들이 어셈블리프로그램이나 기계어프로그램같은 low level 프로그래밍하지 않기 때문에 우리는 symbolic하게 address를 인지하기 때문에 컴파일러와 링커가 보는 주소가 됨

지금은 CPU와 MMU가 하나의 CPU칩에 들어감

그래서 마치 물리메모리가 나오는 것처럼 착각을 할 수 있지만  CPU core가 내보내는 주소는 logical 주소라는 점을 볼 수 있음 

이것을 기본 배경으로 알아야 하고 CPU가 주소를 생성하면 MMU가 동작해야 겠죠

MMU가 제일 처음으로 하는 동작은? table lookup

어떤 세그먼트에서 나온 주소가 있으면 그 세그먼트가 무엇인지를 알아서 세그먼트 테이블에 해당 entry를 찾아 base address를 가져오는 것

예를들어 instruction 패치 주소가 나왔을 때 이 주소는 text segment다

global 변수를 접근하는 주소가 나왔을 때 이 주소는 data segment다

이런 것을 알아야겠죠 어떻게 알 수 있을까요?

결국 logical address가 모여있는 공간인 logical address space를 어떻게 분할하는가를 생각해 보면 됨

예를들어 32비트 머신이 있다고 했을 때

모든 프로세스는 0번지부터 2^32 -1까지의 주소를 갖음 (논리적 주소기 때문에 많이 만들어도 됨)

physical address는 1개 밖에 없지만 logical address는 수행중인 프로세스 개수만큼 

좀더 확장해서 생각해 본다면 링킹이 되는 모든 프로그램에 별도로 한 개씩 갖음

메모리가 0번지부터 2^32 -1까지의 주소를 갖고 있다고 했을 때 

메모리 세그먼트를 어떻게 할당하느냐? 

이렇게 위처럼 분할하면 됨

MMU가 어느 주소가 나왔을 때 어느 section에 속해있는지 알 수 있을까? 

code는 상위 2비트가 00 으로 시작할 것이고

Data는 01, stack은 10, unused 11 로 시작할 것임 그리고 나머지 각각 30bit가 뒤에 따라 나오게 됨

다시 말해 이와같은 layout을 하게 된다면 30bit는 세그먼트 내에 offset으로 사용하게 될 것이고 

상위 두 비트는 세그먼트 ID로 사용될 것임 

이 세그먼트 ID가 세그먼트 테이블에 인덱스가 됨

세그먼트 테이블에 무엇이 있을까?

- base address (그 세그먼트가 어디서 부터 시작하는가)

- bound address (그 세그먼트 크기가 얼마인가)

- RW (그리고 Read segment인지 write segment인지 read only segment인지 알려주는 정보)

Q. Segment Table의 Base Address는 Logical Address인가 Physical Address인가?

A. Physical Address이다.

MMU입장에서 테이블을 살펴보려면 인덱스만 알아서는 안됨 그 테이블의 시작 주소를 알아야 함

Segment Table Base Register (STBR)

Segment Table의 시작 주소를 가리키는 MMU의 Register

MMU는 하드웨어인가 소프트웨어인가? 하드웨어

MMU의 존재가 OS에게 transparent(알기 쉬운, 투명한) 한가? transparent하지 않음

모든 프로세스는 자기만의 segment table을 가지고 있어야 함

그리고 프로세스가 context switching을 하게 되면 

OS는 지금 들어오는 프로세스의 segment table의 시작 주소를 MMU안에 있는 STBR에 reload해 줘야 함

(이것을 reload해주지 않으면 엄한 process table을 뒤지고 있게 됨)

Context가 바뀌면 table을 switching해줘야 함

지금까지 process context switching할 때는 CPU register 값들만 바꾸는 것을 말했음

이제는 table을 바꿔줘야 함 (MMU 안에 있는 STBR 값을 바꿔줘야 함)

그래서 Multithreading을 공부할 때 프로세스를 사용하면 너무 heavyweight 하다

context switching하는데 비용이 너무 많이 든다라고 했는데 

이 table switching 때문에 그런 것

segment table은 entry 개수가 많든 상관 없지만

만약에 paging을 하게 되면 table 이 굉장히 커짐

table들이 Physical memory에 다 있지 못함 

(디스크에 있다가 가져오고 그래야 함)

context switching 오버헤드가 점점 증가하게 됨

address translation을 어떻게 하는지 과정을 보면서 설명

Logical Address 0x1600의 Address Translation

- 제일 밑에 있는 12bit 그대로 내려 오게 됨

- 맨 앞에 1이 01 segment number가 됨

- 01 segment는 실제 물리메모리의 0번지에 저장이 되어있으니 0000을 더하게 되면 

- 0x600으로 address translation이 일어나게 됨

- 이와같이 table-driven segmentation을 하게 되면 상위비트를 통해서 segment number를 얻고 그것을 index로 한 다음 MMU가 갖고 있는 segment table base address register를 통해서 segment table을 찾고 이 index를 이용해서 해당 entry를 얻어오고 거기서 base register값을 얻어오는 것

그리고 bound register값과 비교해서 전체가 벗어나지 않는다면 valid(유효한, 타당한) address임을 확인 할 수 있음

Q. 0x1600의 Address Translation이 일어나는 경우 bound 0x4FF를 넘어가지 않는가?

A. 좋은 지적이다. 이 경우 Memory Fault가 발생한다.

이 경우 bound protection error가 발생한다 

얘는 제대로 translation이 일어나지 않고 memory fault가 발생해서 S/W interrupt가 발생하고 그 프로세스가 죽게 된다.

Q. 0x3002는 어떤 문제가 발생할까?

A. unused되지 않는 unused segment기 때문에 unused segment access하니까 이것도 memory fault가 발생한다

그런데 만약에 예를 들어서 0번 segment에 속한 address를 가지고 write operation하려고 한다면

read / write protection 즉, access privilege에 violation(위배, 침입)이 발생함

이런 경우 인터럽트가 발생한다 (H/W적인 인터럽트는 아니고 OS가 발생시키는 Fault. memory protection Fault가 발생되어 그 프로그램의 수행은 일반적으로 terminate되는 상황이 됨) 

이것이 바로 Segmentation이 됨

지금까지 single segment process의 문제점을 해결하기 multiple segment를 지원해주는 segmentation에 대해 살펴보았음

segmentation은 문제점도 갖고 있음

- 가장 심각한 문제는 메모리를 access하기 위해서 실제적으로는 2번의 메모리 access가 필요

왜? 1. MMU가 segment table의 entry를 가져오기 위해서 

      2. address translation이 발생한 후 physical address가 되면 그때 또 접근

일반적으로 메모리를 access하는 연산은 CPU가 굉장히 느린 Operation임

프로그램의 수행이 그대로 냅두면 2배이상 더 나빠지는 문제가 발생함 (주목해야 할 점)

- segment가 main memory에 많이 존재하다 보니 fragmentation 발생

그냥 냅두면 지난시간에 배웠던 dynamic allocation의 문제인 fragmentation가 발생

- stack segment를 할당했음 function call(함수 호출)에 nesting depth가 점점 더 깊어지면 stack 사이즈가 점점 overflow하게 됨

주어진 stack segment보다 stack 이 더 자라서 자기 공간을 넘어가게 되는 경우도 발생함

이런 경우에 에러처리를 할 수도 있지만 OS이 필요한 만큼 stack segment를 키워줄 수도 있음

어떻게 필요한 만큼 stack segment를 키워줄 수 있을까?

1. (위쪽이 비워있는 공간이라면) 그냥 키워주면 됨

2. (위쪽에 이미 프로세스가 있는 공간이라면) 그 위쪽 segment 가 지금 당장 하용하지 않는다면 디스크로 swap out시킨다.

3. 메모리를 필요로 하는 segment를 디스크로 보낸다. 그리고 나서 나중에 충분한 공간이 생겼을 때 불러들인다.

새로운 프로세스를 메인메모리로 불러 들이고 싶은데

그때 필요한 메모리 공간이 충분하지 않으면 어떻게 하냐?

- 이때도 swapping을 통해 해결할 수 있음

segmentation은 과거 single segment의 문제점을 많이 해결 했지만 

fragmentation 문제에 대한 심각한 현상들은 피해갈 수 없다는 점이 가장 큰 단점 

Paging

dynamic allocation을 할 때 fragmentation이 왜 생긴다고 했었죠?

fragmentation이 발생하는 가장 큰 이유는 프로세스들이 dynamic하게 요구하는 메모리 크기랑 메모리의 크기가 그때 그때마다 다 다르기 때문

다시말해 Memory allocation request의 size가 다르기 때문에 생기는 것임

여기서 숨어있는 insight가 있음

Memory allocation request를 하면 전체 메모리 공간을 physical memory 상에서 continuous(계속 이어지는)하게 할당해야 한다는 것도 들어있음

그래서 이 fragmentation을 없애려면 

Memory allocation을 할 때 unit size로 allocation하면 fragmentation은 없어짐

내가 원하는 메모리 크기가 unit size보다 커진다 했을 때 어떻게 하느냐

걔네들을 continuous하게 할당하지 말고 존재하는 unit 사이즈 만큼 다 모아서 할당

이런 아이디어에서 착안한 기법이 paging임

Paging은 OS의 메모리 관리에서 가장 근간을 이루고 있는 기법이기 때문에 열심히 살펴보겠음

segmentation은 프로세스의 여러 memory section의 속성이 다르고 sharing을 원활하게 해줄 수 있다는 장점이 있지만

fragmentation 문제 때문에 그것만 가지고 사용할 수 없음 그래서 paging을 도입하게 됨

paging은 프로세스가 사용하는 메모리 할당량을 페이지라고 하는 unit 사이즈로 하는 것!

이렇게 함으로써 memory allocation이 굉장히 쉬워지게 됨

또 하나 segmentation에 봤듯이 여러 프로세스가 degree of multiprogramming(다중 프로그래밍 시스템에서 동시에 처리가 가능한 작업이나 프로그램의 수) 이 굉장히 높은 숫자로 수행하게 되면 메모리 공간이 모자르게 됨 그럴 때는 swapping을 해야 함 

swapping은 segmentation할 때 segment들이 스왑의 단위가 됨

그런데 paging의 경우 unit 사이즈의 메모리 공간을 단위로 swapping을 할 수 있음

여러가지 측면에서 메모리 관리가 단순해 짐

paging을 공부하기 전에 알아둬야할 가장 중요한 용어가 2가지 있음 (page와 frame)

page의 가장 기본적인 아이디어는 logical address space를 일정한 크기의 unit 사이즈 메모리로 나누는 것임

그리고 이 각각의 unit 사이즈 메모리를 page라고 부름

Page: Logical Address Space를 일정한 크기로 나눈 Memory Block

여기서 logical address space를 일정한 크기의 unit 사이즈 메모리로 나누는 것이 아니라

physical address space도 일정한 크기로 나눔

그리고 이 크기는 page의 크기와 정확히 일치함

이 각각의 unit 사이즈를 physical 에서는 frame이라고 부름

또는 page frame이라고 부름

Frame: Physical Address Space를 일정한 크기로 나눈 Memory Block. Page와 크기가 동일하다

결국, paging이라고 하는 것은 virtual address나 physical address를 동일한 크기의 일정한 memory block으로 나눈다음 memory allocation 또는 memory management 하는 기법이다.

이와같이 전부 동일한 크기로 메모리 할당이 일어나니 fragmentation 문제를 완벽하게 피할 수 있게 됨

paging할 때 memory allocation을 어떻게 하냐?

각 프로세스가 가지고 있는 메모리 공간들을 어떻게 할당 하느냐?

이것을 우리가 공부해야 하고 가장 중요한 메커니즘이 됨 

- 페이지의 가장 큰 키는 logical address space와 physical address space를 일정한 크기로 나누는 것임

- 그렇다면 어떤 크기로 나누는 것이 좋을까? 

- 과거에는 작은 페이지 였으나 지금은 점점 페이지의 크기가 커지고 있음 

   (bus의 bandwidth가 커지고 memory의 크기도 커지고 하니까 여러가지 이유로 인해서)

- 그런데 과거에 페이지 사이즈를 결정할 때는 주로 swapping을 염두해두고 페이지 사이즈를 결정했음

   (디스크 같은 볼륨디바이스를 다른말로 block디바이스라고 부름. block 디바이스는 I/O transport의 unit이 한 block임)

   이 block 사이즈와 일치시켜서 page 사이즈를 설정했음. why? swapping할 때 one operation으로 1page를 swapping하려고

   그런 취지를 사용해서 page사이즈를 결정했음

- 그런데 요즘에는 점점 물리메모리 사이즈가 커지니까 그것보다 훨씬 큰 크기사이즈로 결정하게 됨

page에 대해서 이해했으니까 두번째는 address translation을 해야 함

address translation을 어떻게 할까? 이것은 segmentation과 굉장히 유사함

segment table을 이용해서 segmentation에서 MMU가 address translation을 했듯이

paging에서는 page table이라고 하는 unit을 이용해서 H/W MMU가 address translation을 하게 됨

- page table이용해서 MMU가 address translation을 할 때 첫번째로 해야할 일은?

- segmentation에서 MMU가 처음에 했던 일이 segment number를 얻어오는 것이라면

- page에서도 마찬가지로 page number를 얻어오는 것임

- page number를 얻어오는 방법은 segmentation과 똑같이 각 메모리 reference에 address 중에서 상위비트를 page number로 사용하고 하위비트를 page offset으로 사용함

- 위 그림에서 페이지 사이즈는 얼마라는 거죠? 2^12(4096)  즉, 4K 짜리 페이지를 사용한다는 의미

- 나머지 20bit를 페이지 number로 사용하게 됨. 거의 1M 100만개에 해당하는 페이지가 virtual address space에 존재한다는 것

- 상당히 많은 수의 페이지가 페이징에서 존재할 수 있다

MMU가 하는 translation은 명확함

page number를 이용해서 page table을 살펴보고 page frame number를 얻어오는 것

이와 같은 address translation을 하려면 MMU에 segmentation과 똑같이 PTBR이 존재해야 함

그리고 OS는 context switching이 발생할 때마다 이 PTBR 값을 새로운 프로세스의 페이지 테이블 시작주소로 로딩해주는 일들을 해야 함

이것이 페이징의 기본임

Page Table Base Register (PTBR)

Page Table의 시작 주소를 가리키는 MMU의 Register

그렇다면 크기만 다를 뿐이지 segmentation이랑 같지 않나?

여기에 굉장히 큰 차이점이 있음

segmentation에서 실제 segment의 크기는 가변적임 (그것을 표현하는 것이 bound register 값이고 )

그 대신 paging에서는 page의 크기가 다 일정하다 

이로 인해 fragmentation을 없앨 수 있게 됨

페이징을 하면 fragmentation을 없앨 수 있지만

약간 다른 형태의 fragmentation을 초래함

그것이 internal fragmentation이라 함

실제로 logical address space에 마지막 페이지가 page boundary에 딱 안맞을 수 있음

평균 잡아서 page 사이즈의 절반정도는 사용이 안되게 됨

이런 것을 internal fragmentation이라 함

하지만 페이지 사이즈가 작으니까 internal fragmentation은 심각한 문제가 아니다

paging을 사용했을 때의 장점과 단점 

장점

- fragmentation이 없다. 

- swapping이 굉장히 용의해진다. (아예 용의하도록 디스크 block사이즈와 페이지 block사이즈를 맞췄기 때문)

- memory allocation도 굉장히 용의

단점:

- segmentation과 똑같은 단점이 있음 

   address reference 가 1개 날아갈 때마다 physical memory reference를 두번 해야 함

   why? 페이지 테이블에서 entry 가져오려고

   또 한번은 실제 데이터를 또는 instruction 가지고 오려고

페이징에 심각한 문제가 있음

segmentation과 달리 페이지 테이블에 크기가 너무너무 방대해지는 문제가 생김

segmentation에서는 segment table의 entry가 어떻게 생겼는지 살펴 보았죠?

paging에서 page table의 entry가 어떻게 생겼는지 살펴볼 필요가 있음

예를들어서 32bit 머신을 얘기하고 있다고 하면

32bit 머신은 1 word가 32bit라는 의미

그렇다면 페이지 테이블의 entry도 1 word의 크기에 align 하는 것이 좋음

페이지 테이블이 있으면 (물론 시작주소를 MMU에 있는 PTBR가 포인팅 하게 됨

그리고 여기에 2^20만큼의 페이지 테이블 entry가 존재하게 됨 (맨 위 예시를 그대로 적용)

이 페이지 테이블 entry에는 어떤 정보가 있을까?

Physical address ? 

(32bit 머신인 경우 Physical address 32비트 임. 

그러면 여기에 페이지가 저장된 Physical address를 다 기록하면 추가적으로 정보를 열수가 없음. 

그렇다면 다 저장할 필요가 있을까? 없음. 

왜냐? 12bit는 페이지 offset으로 사용이 되기 때문에 페이지가 실제로 저장된 곳에서는 전부 0000일 거임. 

page frame boundary는 전부 offset이 0이기 때문에 굳이 0을 다 저장할 필요 없음 그래서 결국 상위 20bit 만 사용함  )

이 20bit의 정보가 frame number가 됨

그렇다면 하위 12bit가 남음. 이것은 무엇으로 사용할까?

그 페이지를 표현하는 여러가지 속성들 (뒤에서 자세히 설명됨)

- 이 페이지가 mapped page나 cashed page지냐? 아니면

- 아니면 이 페이지가 memory를 resident하냐? swap device냐? reference 된적이 있냐?

- 기타 등등 여러가지 정보들을 이 뒤에 넣게 됨

정리!!!!

page table entry는 word 사이즈에 align 되어있고

가장 중요한 정보는 page frame number가 들어가는데 걔는 Physical address는 아니고 말 그대로 frame number다

이 사실을 인지하면 된다

다시 페이지의 단점으로 돌아가서 

페이징을 하게 되면 segmentation과는 달리 추가적인 더 큰 단점이 존재함

그것이 바로 어마어마한 페이지 테이블 사이즈임

예를 들어 어떤 머신을 한번 생각해 보면

이 머신은 32비트 머신이고 1KB 짜리 페이지를 사용합니다

페이지테이블의 사이즈는 

전체 32bit address 중에 10bit를 offset으로 사용하고

22bit 를 page number로 사용

그렇다면 결국 페이지의 개수는 2^22

한 페이지 마다 entry가 1 word 라고 했으니까 4B

2^22 * 4B = 16MB가 페이지 테이블을 위해서만 존재하게 됨

context switching을 할 때 오버헤드가 굉장히 크다 

그래서 multithreading이 나왔고 multithreading은 address space를 공유하는 thread of control이다라고 했지만

address space를 공유한다는 말은 무엇일까?

그리고 address space를 유지하려면 memory overhead 또는 run-time overhead가 많이 드는가?

이것은 전부 굉장히 큰 크기의 페이지 테이블을 유지해야 하기 때문이다.

당연히 16MB의 페이지 테이블을 다 메인메모리에 넣을 수가 없으니까

디스크에 swap 시켜야하는 operation이 필요하게 된 것임

그렇게 되면 context switching할 때 디스크 operation들이 개입을 하게 되니까

굉장히 큰 문제가 발생할 수 있음.

그리고 이 머신들은 요즘 머신들이 아님

32비트 머신이라고 하면 10년전 15년전 이야기

그때는 메모리 사이즈가 64MB였기 때문에 어마어마하게 큰 오버헤드가 되는 것임

- internal fragmentation 문제

존재는 하지만 그렇게 심각한 문제는 아니다.

Q. 지난 시간 Dynamic Storage Allocation에서 이야기한 Fragmentation은 External Fragmentation을 의미하는가?

A. 그렇다. 일반적으로 Fragmentation이라고 하면 External Fragmentation을 의미한다.

지금 사용하는 대부분의 OS는 거의 예외없이 paging을 사용하고 있고

이것을 지원해주기 위한 하드웨어 MMU가 칩에 다 구현이 되어있음

여기서 스토리가 다 끝난 것 같지만 끝이 아님

지금 배울 내용은 paging과 segmentation을 결합시키는 paged segmentation임

왜 paged segmentation이 나왔는가?

segmentation도 어떤 문제를 해결 했음

paging은 segmentation의 문제를 해결 함

그런데 왜 paged segmentation을 할까?

왜 필요할까?

paging만 한다는 것은 뭔가?

프로세스의 1개의 segment만 제공한다는 의미임

그것은 원래 segmentation이 하지 않으려고 했던 문제임 (개선하려고 했던 문제)

즉, paging만 한다는 것은 fragmentation의 문제는 해결했지만 프로세스에게 multiple segment를 할당해야 한다라는 원래의 목적은 달성하지 못함

이 두가지가 다 쓰게 되려면 paging과 segmentation을 실제로 섞어야만 함

이것을 paged segmentation이라고 함

---

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=667

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=668