티스토리 뷰
System내의 Memory상에서 쓰이는 address는 크게 두가지가 있다.
CPU는 Virtual Address, Memory는 Physical Address를 사용하는데, 실제로 데이터를 가지고 있는 주체인 Memory 관점에서 보면 실제로 저장되는 공간을 물리적으로 표현하는 것이고, CPU는 이 주소를 간접적으로 표현하기 위해 이렇게 구분 지은것으로 이해하면 좋을 거 같다. 아무튼 CPU와 Main Memory 사이의 주소 체계가 다르기 때문에 이를 중간에서 변환할 요소가 필요한데 이걸 Memory Management Unit (MMU)라고 한다. 물론 위 그림에서 CPU와 MMU 사이에는 SRAM으로 구성된 cache도 포함되어 있어야 하겠지만, 여기서는 생략되었다.
그럼 이 MMU가 address를 변환하는 과정은 어떻게 될까? 간단하게 이렇게 된다.
보통 MMU는 CPU에 포함되어 있는 형태가 대부분인데, 여기에는 Page Table, 혹은 Page Map이라고 하는 일종의 lookup table이 들어있다. 말그대로 CPU가 Memory의 특정 영역을 읽어오고자 한다면 CPU는 자신이 가진 Virtual Address를 통해서 Page Table의 해당 index에 있는 Physical Address를 접근하게 된다. 이 Page Table은 보통 OS에서 관장하는데, 사실 OS가 올라가다보면 MMU가 활성화되기 이전에도 CPU쪽에서 Memory의 data를 access해야 되는 경우가 발생하기도 한다. 이때는 Kernel 내에서 보통 phys_to_virt()와 같이 변환 API를 제공하곤 한다.
그런데 경우에 따라서는 Memory에 올라가지 못한 Data도 존재하기도 한다. 이 같은 경우는 Disk에 저장되어있는데, 만약 사용자가 Main Memory상에서 데이터를 못찾은 경우라면 MMU에선 그 즉시 Exception을 발생시키고 Disk로부터 해당 데이터를 Main memory에 load하게 된다.
그런데 사실 MMU가 일일히 virtual address를 가지고 이에 맞는 physical address를 찾아주기란 쉽지가 않다. 또한 요즘과 같이 기가단위 용량을 가진 Main memory를 주소만 가지고 딱 여기다라고 찾기는 어려워졌다. 대신 이 주소 영역을 일부분 나눠 하나의 block 형태로 관리하게 되는데, 이런 block을 보통 page라고 한다. 그러니 앞에서 언급한 page table이란 말 자체도 실은 page의 array table이라고 보면 될거 같다.
전체 virtual address field가 위와 같이 32bit으로 표현될 경우, 하위 p bit을 offset이라고 가정할 때 상위 bit 전부는 Page Number(PN) 라고 정의한다. 간단히 놓고 보면 MMU에는 수십개의 page 들이 있는데, 각각의 page 마다 2^p개만큼의 array가 있다고 생각하면 된다. 그래서 각 영역별로 변환될 주소값들이 들어 있는 것이고, 이게 page size가 된다. 일반적으로 page size는 4KB(2^12)이나 16KB(2^14) 만큼의 크기를 가진다.
참고로 physical address도 동일한 형태의 field로 구성되고 각각의 page와 이에 해당하는 offset을 가진다.
이렇게 page라는 개념을 쓰는 이유는 앞에서도 언급했다시피 하나의 address에 해당하는 정보를 일일히 mapping 하는 것보다 이를 뭉뚱그려서 관리하는 것이 조금더 효율적이기 때문이다. 또한 locality의 특성을 빌어 일반적으로 현재 memory영역에 접근했을 경우, 다음 순간에는 동떨어진 영역이 아닌 이전에 접근했던 영역의 주변이 되기 때문에 이처럼 page 단위로 data를 access하는 것이 좋다.
그런데 이렇게 field의 구분을 일부러 이렇게 했을까? 진짜 경우에 따라서는 상위 bit field를 offset으로 하고 Page number field를 하위로 두었을 수도 있었을 것이다. 사실 생각해보면 page size보다는 해당 page 갯수가 훨씬더 많을 것이고, memory의 크기에 따라서는 이 offset에 해당 영역이 아닌 page number의 수가 늘어나기 때문에 추후 확장성을 위해서 이런식으로 이렇게 정한 이유도 있다. 또한 locality 측면에서도 하위bit부터 탐색시 그만큼 주변에서 빠르게 읽을수 있기 때문에 이점을 가질 수 있다.
결국 다시 정의해보면 MMU의 역할은 virtual address를 physical address로 바꾸는 것보다는 virtual page를 physical page로 mapping 시켜주는 것이라고 보면 될것 같다.
그런데 만약 CPU가 virtual page를 이용해 어떤 memory area에 접근했을때 그에 mapping되어 있는 physical page가 없는 경우는 어떻게 될까? 보통 이런 경우를 page fault, page miss라고 하는데, 이런 케이스는 일반적으로 해당 데이터가 disk같은 secondary storage에 있는 경우이므로 거기서 데이터를 읽어오고, 여기에 해당하는 physical page를 page table에 업데이트하게 된다.
전체적인 동작을 살펴보면 CPU와 memory, 그리고 disk사이에서 page table이 일종의 cache와 같은 역할을 하는 것처럼 보인다. 뭐 표현을 page cache라고 할 수도 있겠지만 이런식으로 사용자에 따라서 page가 disk와 CPU, memory 사이를 이동하는 동작형태를 paging, 혹은 demand paging이라고 부른다.
아마 다음 포스트에서는 이 MMU의 자세한 동작 원리에 대해서 다뤄보려고 한다.
'Study > Architecture' 카테고리의 다른 글
[Architecture] Building the MMU (1) (0) | 2016.06.30 |
---|---|
[Architecture] Page faults (0) | 2016.06.29 |
[Architecture] Basics of Virtual Memory (2) (0) | 2016.06.26 |
[Architecture] Memory Hierarachy (0) | 2016.06.12 |
[Data] Error Correction (0) | 2015.09.10 |
[Data] Huffman`s Algorithm (0) | 2015.09.07 |
[Data] Variable Length Encoding (1) | 2015.09.07 |
- Total
- Today
- Yesterday
- Kinect for windows
- Pipeline
- TensorFlow Lite
- ColorStream
- RL
- reward
- Windows Phone 7
- bias
- End-To-End
- 딥러닝
- Expression Blend 4
- 한빛미디어
- 파이썬
- ai
- Offline RL
- Kinect SDK
- DepthStream
- Distribution
- Variance
- Gan
- 강화학습
- windows 8
- arduino
- processing
- Policy Gradient
- SketchFlow
- dynamic programming
- PowerPoint
- Kinect
- Off-policy
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |