[운영체제] 3. 메모리 관리(2/4)

3.3 가상 메모리

 

리얼 메모리의 비효율성을 개선한게 가상 메모리 시스템

 

버츄얼 메모리 : 프로세스한테 피지컬 메모리에 대한 정보를 감춤

 

n이 바로 cpu가 한번에 처리할 수 있는 워드의 크기는 word size, CPU의 비트를 따라감.

프로세스는 무제한인 메모리 공간에서 실행할 수 있고다고 착각하게 됨

-> 특정 시점에 사용되는 부분만 메모리에 두고 실행시키면 되지 않냐? <- 때문

3.3.1 페이징(지금의 모든 시스템은 페이징 시스템을 사용)

 

가상 메모리 공간을 똑같은 사이즈의 page로 나눔 -> 가상주소는 페이지의 번호와 페이지 내부의 offset으로 표현이 됨

-> 32비트라고 했을 때, 페이지의 크기가 4k라고 하면 12bit가 offset, 나머지가 페이지 번호

 

virtual memory space에는 코드, 데이터, 힙, 스택이 존재.

물리 메모리 역시 똑같은 사이즈로 나누어짐. 물리메모리를 나눈건 페이지 프레임이라고 함.

-> 페이지는 연속되어 있지만, 실제 물리 메모리에 로드될 땐 연속지 않을수도 일부는 디스크에 파일의 일부로 저장될 수도 있음.

 

p의 가상주소 공간은 페이지 단위로 나뉘어져 있음. 피지컬 메모리 역시 페이지사이즈와 똑같은 페이지프레임으로 나뉘어야함.

가상 주소가 20비트, offset이 밑의 10비트, 위의 10비트는 페이지 번호

피지컬 주소는 offset이 10, 실제 피지컬 메모리 사이즈는 6개. -> 페이지 번호를 프레임 번호로 바꾸어야 하고,

page table : 가상 주소를 피지컬 프레임으로 변환하는 역할

프로세스마다 페이지 테이블이 필요. 페이지 테이블은 process status의 일부.

2장의 프로세스 테이블을 보면, 메모리 관련 정보가 저장 -> 그 중 일부가 페이지 테이블.

프레임 번호 뿐만 아니라 flag정보도 포함 -> Protection bit(보호 비트(밸리드 비트):접근 허용 여부 표시)와 modified bit(수정 비트or더티비트 : 페이지 프레임을 교체할 때 기록해야 하는지 마는지 페이지의 상태를 반영), 참조비트(교체할 페이지프레임 선택시 사용), 캐시 무효화 비트(해당 페이지가 캐싱될 수 있는지 여부) 존재

페이지 사이즈가 1k, 10개가 옵셋, 6비트가 페이지 번호. -> 2^6개의 페이지 테이블 엔트리가 필요.

 

페이지 테이블은 메모리에 있음. 페이지 테이블의 시작 주소를 페이지 테이블 베이스 레지스터에 넣어 놓음

-> 가상주소가 cpu에서 오면, 이 레지스터를 기준으로 메모리의 어디에 있는지 확인

-> 그 offset으로 가서, 페이지 프레임 번호로 변경

 

3.3.3 페이징 속도 향상

 

문제 : 속도. 메모리를 두 번이나 접근해야 하기에 성능이 절반 이하로 줄어듦

해결 : T ranslation L ookaside B uffer

 

페이지 테이블을 통해 한 번 이상 변환된 정보를 TLB에 저장 -> TLB 캐시를 통해 씨피유 내부에서 바로 물리주소로 변경하여 바뀐 주소를 버스에 실어 메모리 컨트롤러로 전송. 비싸지만 hit ratio가 굉장히 높아 가상 메모리 시스템이 잘 동작하게 됨.

-> fully associated 

 

정리

페이징 : 효율적 but 시간이 오래 걸리기에 TLB캐시로 해결.

또한 가상 주소 공간이 너무 큼. 32비트 cpu에서도 프로세스마다 4mb나 필요 -> 효율성에 대한 이슈 여전

TLB는 주소 변환을 효율적으로 만듦.

 

페이징 시스템은 프로텍션이 가능, 쉐어링 존재.