Segmentation and Paging - (3) Paged Segmentation

Segmentation and Paging - (3) Paged Segmentation

Paged Segmentation
- segmentation과 paging 각각의 장점을 한꺼번에 얻기 위해 두 기법을 동시에 사용. 이를 위해 먼저 segmentation을 수행하고 각 segment 별로 paging을 수행한다.

Segmentation의 장점

1. 두 User Process가 동일한 코드(Text Segment)를 공유하기 용이하다.

2. 각 Memory Section들에게 각기 다른 Read/Write 권한을 설정할 수 있다

Paging의 장점

1. Memory fragmentation(external fragmentation)을 없앰

2. swapping이 용이해진다.(=메모리를 분할하는 크기를 swapping단위로 만들면 된다.)

<그림 1: virtual address>

<그림 2:Segment Table, Page Table>

기존의 Segment Table은 Base address에 해당 segment의 base address가 적혀 있었고 이 값에 offset을 더해 physical address로 변환하였다. 그러나, Page segmentation기법에서는 segment table의 Base address에는 해당 segment의 page table base address값이 적혀져 있다.

이 값을 얻고 해당 주소로 접근해서, virtual address에 있는(Page#)으로 해당 index에 맞는 page table을 찾으면 그곳에 frame #(=physical)가 적혀져 있다. 이 값에 offset을 더해 최종적으로 physical address가 구해진다.

예를들어, 0x002070라는 virtual address가 어떻게 변환(translation)되는 지 살펴보자

0x002070는 상위 4bit가 0x0으로 Seg # : 0이다.
Page #은 0x2이다.
offset은 0x070이다.

따라서, 위 segment #0에 해당하는 page table의 base address(0x2000)에 접근한다.
0x2000에서 page#(0x2)이므로, 0번째 : 0x0013, 1번째 : 0x002A, 2번째 : 0x0003
으로 frame# 변환이 이루어지고 이 값에 offset을 더한다.

최종적으로, 0x003070의 physical address를 얻는다.

Paged Segmentation을 위해 기존 segmentation에서 변경되는 부분

1. 기존 Base address대신 해당 segment의 page table address를 저장

2. 기존 Bound값 대신 해당 segment의 page 개수를 저장

Paged Segmentation의 가장 큰 단점은?
- address referencing이 one-way가 아닌 three-way로 이루어져 성능저하가 발생한다.(오버헤드)

Segment Table과 Page Table을 사용한 주소 변환
- MMU에 의해 하드웨어적으로 수행된다. 그러나, 프로세스의 context-switching이나 새로운 프로세스 생성이 일어날 때, 운영체제가 base/bound register, segment/page table을 관리(STBR값 변경)해야 하므로 운영체제에 transparent하지 않다.

Q. 운영체제에서 machine-independent한 코드의 비중을 가능한 높이는 이유는?
- 운영체제의 portability를 높여 다른 하드웨어에서도 동일한 운영체제를 사용하기 위함.

Q. 어쩔수 없이 machine-dependent한 운영체제 코드는?
- context-switching, 프로세스 생성, I/O 관리, 메모리 관리(memory management, segment table, page table)

이러한 paged segmentation기법은 segment table과 page table기법의 장점을 모두 가지나 아래와 같은 오버헤드가 생겼고 이를 극복해야 한다.

1. Large Page Table
2. memory reference 성능저하(3-way)

virtual address space상에 존재하는 page 블록들은 각각의 특성을 고려해 아래와 같이 분류할 수 있다.

1) mapped page
- memory translation이 일어나는 page( virtual address -> physical address)
2) unmapped page
- 직접 physical address를 사용해서 별도의 주소변환(memory translation)없이 바로 접근가능하다. ex. page table address
3) cached page
- cache기법을 사용하는 page.
4) uncached page
- cache하지 않도록 설정된 page. DMA 대상 page처럼 여러 프로세스에 의해 동시에 읽고 쓰기가 일어날 수 없는 경우 사용.(cache coherence 문제)

Large Page Table

Large Page Table이 왜 문제가 될까?
- physical memory space에 너무 많은 용량을 차지함(ex.16MB) 프로세스 1개당 1개의 page table을 지니므로 degree of multi-programming이 높을수록 컴퓨터 시스템의 부담이 더욱 늘어남

Q. Large Page Table 문제 해결방법?
1. Page Table의 크기를 줄인다.
2. 연속적인 메모리 공간 요구량을 줄임(-> virtual address에 page table을 존재시켜 page table의 각 entry가 가상 메모리 공간에서는 continuous하나 physical memory상에는 불연속해도 되게끔 허용 + swapping)

memory reference 성능저하(3-way)

TLB(Translation Look-aside Buffer)
- 자주 reference되는 page table entry를 메인 메모리가 아닌 캐시(cache)에 적재시킴으로써 memory reference 오버헤드를 줄여 성능향상을 기대하는 기법.

Cache 성능을 높이는 방법?
- cache를 크게 만든다?
- 프로그램의 Locality속성 때문에 큰 크기가 필요 없다.
- spatial locality(instruction 주변에 있는 다른 instruction이 접근되는 특성)
- temporal locality(동일한 instruction이 다시 접근되는 특성)
- 프로그램의 loop(for문) 때문에 위 특성이 나타난다.

<그림 3:TLB>

TLB는 다른 캐시기법과 마찬가지로 아래와 같은 기법이 사용된다.
1. Direct mapped cache
2. Associative mapped cache
3. Set associative mapped cache

TLB entry는 Frame #(변환이 될 physical address), Page #(TAG, 이것을 비교하여 hit/miss 판단) + bit field(특성)으로 구성된다.

TLB는 운영체제에 transparent하지 않다.
왜냐하면, context-switching이 발생하면 각 프로세스는 virtual address를 사용하므로 TLB에 내용이 남아있으면 혼선이 발생한다. 이를 해결하기 위해 운영체제는 context-switching이 발생하면 TLB를 flush한다.(내용을 지움)

Q. TLB를 운영체제에 transparent하게 만드는 방법(MIPS)
- Page Number와 함께 PID(=ASID)를 추가적으로 사용해서 각 프로세스를 구분짓는다.