가상 메모리

해당 게시글은 kocw에서 제공하는 금오공과대학교 최태영 교수님의 무료 강의를 공부하고 정리하기 위해서 만들어졌습니다.

Virtual Memory

• 실재 존재하는 것처럼 보여주는 가상의 메모리 이다.
• 적은 용량의 메모리를 사용하면서 프로세스가 마치 더 큰 메모리 영역을 사용하는 것처럼 사용하도록 제공해준다.
• 어떤 내용의 page를 메모리에 올릴지 고민하는 것부터 시작된다.
• PC가 수행되는 페이지와 메모리에 접근하는 페이지만 실제 메모리에 올라와 있으면 프로그램 수행에 문제가 없기 때문에,
• 사용되는 페이지만 페이지 테이블에 매핑하여 실제 메모리에 올려준다.
• 나머지 페이지는 메모리에 올리지 않고 하드디스크에 저장해 놓는다.
• PC가 다음 페이지 영역의 코드를 실행하게 되면 그 때 되어서야 페이지 테이블에 빈 프레임을 매핑해서 메모리에 올리게 된다.
• 이것이 가상 메모리가 동작하는 방식이다.
• 이런 방식을 사용하면 3가지 이점이 생기게 된다.
  • 1. Physical Memory 영역보다 더 큰 프로세스를 실행 가능하다.
  • 2. 실제 수행하는 프로세스의 전체 크기와 상관없이 수행되는 메모리 영역은 작다.
  • 3. 그만큼 더 적게 I/O를 사용하기 때문에 cpu에 더 투자할 수 있다.
• 가상 메모리를 구현하기 위해 페이징 방식에서 조금만 변경하면 된다.
• 그렇게 변경된 것을 Demand Paging이라고 한다.
• 또한 Segmentation을 virtual memory로 사용할 수 있게 만든 것을 Demand Segmentation이라고 한다.
  • 두 가지의 기능은 거의 동일하다.

Virtual-address Space

• 프로세스가 가변공간을 가지는 이유가 가상 메모리 주소 공간을 사용하기 위함이다.
  • 대부분의 시스템이 이 가상 메모리 공간을 제공해준다.
  • 가변공간이 가상 메모리 주소 공간이다.
• 이런 가변공간은 stack과 heap 영역이 자유롭게 늘어나기 위함이기도 하지만,
• 스탠다드 라이브러리처럼 신규로 개발한 라이브러리 들을 올려두기 위한 용도로도 쓰인다.

Demand Paging

• 부분적인 페이지만 올려서 프로세스를 실행하는 방식이다.
  • 현재 실행중인 영역과 사용중인 메모리 영역만 올린다.
• 현재 사용중인 페이지만 페이지 테이블에 매핑정보로 등록되기 때문에,
• 신규로 사용하기 위한 페이지를 페이지 테이블에서 찾으려면 없는 경우가 발생한다.
• 이 때 페이지를 실제 메모리에 올리는 과정을 거친다.
• 페이지 단위로 Swapping이 발생된다.
  • 이전에는 프로세스 단위로 올리는 것을 Swapping이라고 했는데, 이제는 페이지 단위로 동작 해야한다.
• 이런식으로 스와핑을 수행하는 것을 Lazy swapper라고 한다.
• 스와핑을 수행하기 위해 스왑해야 하는 페이지가 비어있는지 아닌지 확인하는 과정을 거쳐야 한다.
• 이 것을 확인하기 위해 대부분의 하드웨어에서는 페이지 테이블에 valid/invalid bit를 두어서,
• 메모리에 올라오지 않은 페이지는 invalid로 설정하고, 메모리에 올라온 페이지는 valid로 설정한다.
• 이런식으로 기록된 내용들은 MMU가 읽어와서 사용하게 된다.
  • 따라서 하드웨어적으로 valid/invalid bit이 정해져야 하고,
  • MMU에서도 이것을 읽기 위한 회로가 추가되어야 한다.
• MMU에서 valid/invalid bit를 읽고 invalid 하다면 trap이 발생하게 된다.
  • 이것을 page fault trap이라고 한다.
• 이후 page fault 트랩을 처리하기 위한 인터럽트 핸들러가 수행된다.
• 인터럽트 핸들러는 비어있는 프레임을 찾아서 요청한 페이지를 하드디스크에서 읽어와 메모리에 올리는 과정을 수행한다.
  • 빈 프레임을 찾을 때는 크리티컬 섹션으로 감싼다.
• 이후 페이지 테이블에 프레임 번호를 매핑하고 valid로 bit를 변경한다.
• page fault trap은 일반적인 trap과 많이 다르다.
  • 예를 들어 divide by zero 트랩 같은 경우 프로세스를 죽여버린다.
  • 또한 software interrupt(system call)는 일을 처리하고 돌아와서 다음 명령을 수행한다.
  • 그러나 page fault 트랩은 인터럽트 핸들러를 수행하고 트랩을 일으킨 명령을 다시 수행한다.
  • 페이지를 메모리에 올리고 다시 페이지를 찾는 과정을 거친다.

Aspects of Demand Paging

• Pure Demand Paging
  • 일반적으로 프로세스를 실행하기 위해 아이콘을 더블 클릭 하면 new 상태의 프로세스가 생성이 되고,
  • 메모리에 프로세스에 올려서 프로세스를 ready 상태로 변경한다.
  • 그러나 pure demand paging을 사용하게 되면,
  • new 상태의 프로세스가 생성되고 바로 ready 상태로 프로세스가 변경된다.
  • 이렇게 올라간 프로세스는 페이지 테이블이 생성되고 페이지 테이블 내부에서는 모든 페이지가 invalid 상태로 등록이 되게 된다.
  • 프로세스가 실행되면 PCB 내부의 PC는 0번째 페이지를 가리키기 때문에 바로 page fault가 발생하고 페이지를 메모리에 올리는 과정을 수행하게 된다.
• 현실적으로는 Pure Demand Paging을 사용하진 않고, 몇 개의 페이지를 미리 올려둔 상태에서 실행하게 된다.
• 그렇게 페이지를 메모리에 올리는 명령을 수행하게 되는데,
• 어떤 명령은 block copy가 발생하여 한 페이지가 아니라 두 개의 페이지를 올려야 하는 상황이 발생하게 된다.
• 따라서 하나의 페이지에서 콜백이 발생하는 것이 아니라 여러 페이지에서 콜백이 발생할 수도 있다.
• 하드웨어적으로 MMU에서 사용하기 위한 구조도 만들어져 있어야 하고,
• page swap out이 가능하도록 제공해 주어야 한다.
• 또한 system call인지 page fault인지 판단하고 다음 명령을 수행하기 위한 구조도 되어 있어야 한다.

Performance of Demand Paging

• Demand Paging은 어떻게 보면 성능이 떨어진다.
• 특히 memory access 하는 것을 따지면 성능이 떨어질 수 밖에 없다.
• Demand Paging을 하는 스텝마다 비용이 들어간다.
  • MMU에서 invalid 페이지를 발견할 경우 트랩이 발생하며, 트랩이 발생하는 시간이 소요된다.
  • 트랩이 발생하면 현재 프로세스 컨텍스트를 저장한다. 반쪽짜리 컨텍스트 스위칭이 발생한다.
  • 현재 트랩이 page fault 인지 확인 하는 과정을 거친다.
  • 현재 요청된 페이지가 페이지 테이블 바깥 범위인지 확인 하는 과정을 거친다.
  • 레퍼런스한 페이지를 하드디스크에서 위치를 찾는다.
    • 주로 하드디스크에서 찾는 것은 코드일 경우이며,
    • 때에 따라 하드디스크에서 찾는 것이 아니라 만들어야 하는 경우도 있다.
  • I/O device에게 어떤 페이지를 읽어달라고 요청한다.
  • 요청이 device 큐에 담기고 device는 seek를 하고 rotate를 거쳐 페이지를 찾는다. 이 때 페이지를 읽는 시간이 필요하다.
  • I/O의 작업이 끝나면 인터럽트가 발생하고 인터럽트 핸들러는 현재 수행중인 프로세스를 저장한다.
  • 이후 demand paging으로 부터 시작된 인터럽트인지 확인하고 페이지테이블을 valid 로 수정한다.
  • 이후 해당 프로세스는 ready queue에 들어가게 된다.
  • cpu는 ready queue에서 프로세스를 꺼내서 실행하게 된다.
• 이 중 가장 시간을 많이 잡아먹는 단계를 세가지 살펴보자면 아래와 같다.
  • 1. 인터럽트 서비스 과정
    • 페이지 레퍼런스 확인
    • 비어있는 프레임 찾기
    • I/O 요청
    • I/O 인터럽트 처리
    • 페이지 테이블 수정
  • 2. I/O를 기다리는 과정
  • 3. 프로세스 리스타트 과정
    • 일반적인 경우 시간이 그렇게 오래 걸리지 않지만,
    • 블락 카피가 발생할 경우 시간이 오래 걸릴 수 있다.
• page fault는 매번 발생하지는 않는다.
  • page fault가 발생하는 비율은 0~1 사이이다.
  • Page fault가 발생하지 않는 시스템은 demand paging을 사용하지 않는 시스템이다.
• demand paging이 위 과정을 계산해보면 약 40배 정도 느리다는 결과가 나온다.
• 그러나 실제로는 그렇게 느려지지 않으며, 오히려 더 빨라진다.
• 일반 paging은 처음에 프로세스를 모두 로드 후 수행하기 때문에 점진적으로 프로세스를 로드하여 실행하는 demand paging보다 더 느리게 동작한다.
• 그렇기 때문에 demand paging이 일반 paging보다 더 빠르다고 할 수 있다.