티스토리 뷰

반응형

Segmentation 기법.

 프로그래머가 생각하는대로 메모리를 구분지어주는 메모리 관리기법이다.

 사용자 관점에서 Stack, Data, Symbol Table 등과 같은 커다란 조각으로 논리주소를 분할한다.

 

 각각 Segmentation에는 번호가 System에 의해서 매겨진다.

 따라서 논리주소는 <Segmentation Number, Offset>으로 구성된다.

 그리고 Segmentation Table에 의해서 해당 논리주소는 물리주소로 변환된다.

 

 

결국 목적은 연속된 논리주소를 연속되지 않는 물리주소에 할당시키기 위함이다 !!!

 

Segmentation 기법이 없다면...?

 - 두 User Process가 동일한 Memory 영역을 공유하기가 힘들다.

 - 하나의 Process에서 특정 영역에 따른 권한부여를 할 수 없다.

 

Segmentation의 크기가 커짐에 따라 외부 단편화현상이 발생할 수 있다.

Paging 기법.

 처음으로 외부단편화 방지가 가능한 기법이고, 다양한 측면에서 개선이 이루어졌다.

 

 물리메모리는 Frame이라는 단위로, 논리메모리는 Page라는 단위로 분할한다. (일정한 크기)

 외부단편화는 방지가되었지만 일정한 크기로 분할을 하다보니 내부단편화가 발생한다.

 그렇다고 페이지의 크기를 작게하면 Page Table의 용량이 커지기 때문에 적당선을 지켜야한다.

 

 Process가 실행될 때, 해당 Process의 Page들은 파일시스템 혹은 예비저장장치에 의해 가용가능한 Frame에 적재된다. 그리고 그에 따른 Frame과 Page의 매칭정보는 Page Table에 기록된다.

 ( 반대로 Frame Table에는 총 몇개의 Frame이 존재하는지, 이용가능한 Frame은 몇 개인지에 대해서... )

 

프로그래머는 메모리가 연속적인 하나의 공간이며 메모리 전체에
현재 자신의 프로그램만이 존재한다고 생각한다.

 

Paging은 Context Switch의 시간을 증가시킨다. - TLB (Translation Look-aside Buffers)의 등장 !

                                                                          ( TLB는 일종의 소형 하드웨어 캐시라고 생각하면 된다. )

 

Segmentation과 마찬가지로 Paging 기법에서도 Page단위 공유가 가능하다.

이 경우는 주로 재진입가능코드들이 이에 해당된다. (?) - Read Only 코드들인듯..?

Page Table의 구성 ?

1) 계층적 페이지 테이블

 - 구조자체는 간단해서 설명할 것이 없을듯.. 많은 OS에서 해당 기법을 사용한다.

 - 그러나 64bit 운영체제로 넘어오면서 점점 비현실적이다...

 

2) 해시 페이지 테이블

 - 페이지 번호가 오면 그것을 해싱하고 해시 페이지 테이블에서 탐색한다.

 - 주소구성 : "Page Number , Frame Number , Link"

 - Collision이 발생하지만 링크드리스트를 통해 해결한 테이블이다.

 

3) 역 페이지 테이블

 - 주소구성 : "Process-id, Page Number, Offset"

 - 메모리 Frame마다 하나의 항목을 가진다.

 - 장점으로는 System당 1개의 Table을 가질 수 있다는 장점이 있다.

 - 단점으로는 물리주소로 정렬이 되어있기 때문에 변환시간이 더 오래걸린다는 단점이 있다.

   또한, 메모리 공유에 있어서 어려움이 있다.

 


TLB ?

 ​위에서 설명했듯이 일종의 Page Table의 Cache이다.

 Page Table은 메인 메모리에 저장되기 때문에, 프로그램에 의한 모든 메모리 접근은 최소 두 번 필요하게 된다. 실제 주소를 얻기 위한 메모리 주소 접근(CPU로 부터 생성된 가상주소를 메모리에 있는 Page Table을 통해 실제주소로 변환시킨다) 한 번과 데이터를 얻기위한 또한 번의 접근이 필요하다.

 

 때문에 실제 주소를 얻기 위한 메모리 주소 접근에 앞서 TLB에 해당 Page가 어느 Frame에 할당되어있는지 질의한 후, 물리주소로 변환하게 되면 한 번의 메모리 접근만으로 데이터를 얻어낼 수 있다.

 

 물론 TLB에 해당 데이터가 없으면 TLB Miss가 발생하여 원래의 루틴을 거치게된다.

 

TLB를 크게 만들기보다 여러개를 만들었을 때 적중률이 높아진다.
( 큰 크기가 필요없는건 Program의 Locality 특성 때문이다. )

 

기본적인 TLB에는 현재 실행중인 Page-Frame 정보만 존재한다. 때문에 문맥교환시 반드시 Flush해줘야한다.

그러나, ASID(TLB항목이 어느 Process의 것인지 알려줌)의 지원을 받아 하나의 TLB안에 여러 Process의 정보가 저장될 수 있다.


IA-32 :  테이블디렉토리 Offset(10bit) + 페이지테이블 Offset(10bit) + 변위(12bit)

x86-64 : unused(12bit) + 페이지맵 Level4(10bit) + 페이지디렉토리 포인터 테이블(10bit) +

           페이지 디렉토리(10bit) + 페이지테이블(10bit) + 변위(12bit)

 

반응형
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/05   »
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
글 보관함