📌 Memory Management 3

📖 01. Multilevel Paging and Performance

• 페이지 테이블을 2단계만 쓰는것이 아니라 다단계로 사용한다.
  -> 페이지 테이블에 대한 공간을 줄일 수 있지만 여러 페이지 테이블을 거쳐야 주소변환이 된다.

• 페이지 테이블이라는 것이 물리적 메모리 공간에 있기 때문에 메모리를 4번 거쳐야 한다. (3단계라면)

• 다단계를 사용하더라도 TLB를 통해 메모리 접근 시간을 줄일 수 있다.
  -> 0.02 부분에서 20은 TLB를 확인했다가 실패한 시간
  -> 메모리 접근시간 100을 빼면 주소변환을 하는데 28 걸린다.

📖 02. Valid (v) / Invalid (i) Bit in a Page Table

• frame number말고 부가적인 bit가 더 들어가 있다.

• valid(v), invalid(i)로 표시된 것이 존재한다.

• valid, invalid bit 이외에서 Protection bit이 존재한다.
  -> 어떤 연산에 대한 접근에 대한 것

• 페이지 중에는 프로그램의 코드 부분을 담고 있는 페이지도 있고 데이터나 스택을 담고 있는 페이지가 존재한다.
  -> 코드같은 경우에는 내용이 바뀌지 않아야 한다.
  -> CPU에서 읽어서 instruction하는 역할
  -> 따라서, 코드 영역에 해당하는 경우 read-only로 해놓는다.
  -> 데이터나 스택은 쓰고 업데이트 가능하기 때문에 read/Write에 대한 권한을 줘야한다.

📖 03. Inverted Page Table

• 지금까지 페이지 테이블에서 문제가 되는 것은 굉장히 많은 용량을 차지하고 있다는 것이다.
  -> 주소공간이 허용하는 한도만큼의 페이지 테이블 엔트리가 만들어져야 하고 프로세스마다 각각 주소변환을 해야하기 때문에 각 프로세스별로 페이지 테이블이 만들어져야한다.

• 이런것을 막아보자하는 것이 Inverted Page Table이다.

• 원래 페이지 테이블을 역발상으로 뒤집어 놓은것

• P1이 있다면 P1을 위한 페이지 테이블이 있고 P2가 있다면 P2를 위한 페이지 테이블이 존재한다.

• Inverted Page Table은 시스템 안에 테이블이 딱 하나 존재한다.
  -> 페이지 테이블의 엔트리가 프로세스의 페이지 개수만큼 존재하는 것이 아니고 물리적인 메모리의 프레임 개수만큼 존재하는 것이다.
  -> 첫 번째 엔트리는 물리적인 메모리의 첫 번째 프레임을 나타내는 것이다.

• 우리가 주소변환을 하려면 어떤 페이지 번호를 보고 위에서부터 페이지 번호만큼 떨어진 엔트리에 가서 주소변환을 하는 방법을 사용했다.
  -> Inverted Page Table은 그게 아예 불가능하다.
  -> P번째 주소변환을 하고 싶다면 페이지 테이블의 P번째 엔트리에 가면 페이지 프레임 번호가 나온다.

• 주소변환이라는 것은 로직컬 주소를 보고 피지컬 주소로 바꾸는 것을 말하는데 이 상황은 그 반대의 경우이다.
  -> 목적에 맞지 않는 테이블인데 이 테이블을 사용해서 주소변환을 어떻게 해야할까?
  -> 논리주소에 해당하는 페이지 번호 P가 물리적인 메모리에 어딧는지 알고 싶다면 페이지 테이블을 모두 찾아봐야 한다.
  -> 페이지 테이블의 공간을 줄이기 위해서 사용한다.
  -> 그러나 시간적인 오버헤드가 존재한다.

• 페이지 테이블에 더 저장해야 할 것이 있는데 논리적인 페이지 번호만 저장하면 될 것이 아니라 논리적인 주소 P가 어떤 프로세스의 P번째 페이지인지 저장해야 한다.

• PID와 P로 페이지 테이블에서 찾았다면 그에 해당하는 인덱스를 페이지 프레임 번호로 넣어주면 된다.

• 위에서부터 순차적으로 찾는 것은 적절하지 않다.
  -> 그럼 어떻게?
  -> associative register을 사용하여 테이블을 병렬적으로 검색할 수 있도록 한다.

📖 04. Shared Page

• 프로그램을 구성하는 페이지 중에는 다른 프로세스들하고 공유할 수 있는 페이지가 존재한다.

• 서로다른 프록세스 P1, P2, P3가 존재한다.
  -> 이 프로그램들이 만약에 같은 코드를 갖고 프로그램을 돌린다.
  -> 이러면 코드에 대해서는 같은 것을 사용해도 된다.
  -> 이런식으로 공유할 수 있는 코드를 Shared code라고 부른다.

• 각각을 물리적인 메모리에 별도로 올리는 것이 아니라 공유가 가능한 코드에 대해서는 한개의 카피만 메모리에 올리는 것이다.

• 공유가 가능한 코드는 같은 프레임으로 맵핑시켜 테이블을 만든다.

• Shared code == Re-entrant Code (=Pure code)라고 부른다.

• shared page 기법은 반드시 read-only으로 해야 한다.

• Shared code 즉, Re-entrant Code는 두가지를 만족해야 한다.

1. real-only
2. 동일한 logical address space에 존재해야 한다.

• 컴파일하면 코드 안에 논리주소가 들어가게 되기 때문에 다르면 코드를 실행 할 수 없기 때문이다.

• Inter Process Communication(IPC)와 shared code는 다르다.
  -> IPC는 프로세스간 통신을 목적으로 어떤 페이지를 여러프로세의 주소공간에 같이 맵핑하는 것까지 같은데 read/write를 해놓고 커뮤니케이션을 목적으로 하는 것이다.

📖 05. Segmentation

• 페이징 기법이라는 것은 프로그램을 구성하는 address space를 페이지 단위로 쪼갠 것이고 Segmentation기법은 프로세스를 구성하는 주소 공간을 의미 단위로 쪼갠 것이다. (예를 들어, 코드, 데이터, 스택)
  -> 더 작게 쪼개고 싶다면 함수 단위로

• 세그먼트 번호(s)만큼 떨어진 엔트리에 가면 이 세그먼트가 물리적인 메모리에 어떤 번지에 올라가 있는지를 가지고 있다.
  -> 그런데 Segmentation기법은 entry에 두가지가 존재하는데 물리적인 메모리의 시작위치 이외에 limit이라는 것이 존재한다.
  -> 세그먼트의 길이를 의미한다.
  -> 세그먼트는 각각 길이가 다르기 때문에 필요하다.

• 주소변환을 할 때 크게 두가지를 체크해야 한다

1. 주어지 논리주소에서 세그먼트 번호(s)가 STLR보다 작아야 하며 만약 큰 값을 요청했다고 하면 잘못된 시도이기 때문에 trap이 걸리게 된다.
2. 세그먼트의 길이(limit)보다 offset이 크지는 않은지 확인해야 한다.

• 페이징 기법은 페이지 크기가 균일하기 때문에 offset의 크기가 페이지 크기에 의해서 결정이 된다.

• 그러나 Segmentation기법에서는 offset에 해당하는 부분이 미리 결정되어야 한다.
  -> 세그먼트 길이는 offset으로 표현할 수 있는 bit 수 이상은 안된다.

• 페이징 기법에서는 시작 주소가 프레임 번호로 주어지면 된다.

• 연속할당기법에서 프로그램 크키가 균일하지 않아서 종료될 때마다 여러가지 홀들이 생긴다.
  -> 세그먼트들도 균일하지 않기 때문에 중간중간에 사용되지 않은 메모리 공간이 여기저기 생기게 될 것이다.
  -> 이것이 Segmentation기법의 단점이다.
  -> first fit/ best fit 사용해야 한다.

• 그렇다면 장점은 무엇일까?
  -> 의미있는 단위로 쪼개기 때문에 의미 단위로 일을 하면 Segmentation기법이 효과적이다.
  -> 예를 들면, 프로텍션 하는 경우에 어떤 부분은 read-only로 되어어 있고 어느 부분은 read/write가 가능하고 어떤부분은 실핼 권한이 있고 이런식으로 의미 단위로 실행이 된다.

• 그러나 페이징에서는 동일크기고 자르다보니 코드영역과 데이터영역이 같이 있을 수 있고 이것을 read-only로 해야하느냐 read/Write로 해야하느냐 모호해진다.

• sharing을 할 때도 의미 있는 것끼리 공유하는 것이 맞지 같은 크기로 하는 것은 의미없다.
  

[출처] 반효경 교수님 강의