[운영체제] Memory Management

Logical vs Physical address

• 논리 주소 (virtual address)
  • 0번지부터 시작하는 프로세스마다의 독립적인 주소 공간
  • CPU가 보는 주소
• 물리 주소
  • 메모리에 실제 올라가는 위치
• 주소 바인딩 : 주소를 결정하는 것
  • Symbolic → Logical → Physical

주소 바인딩

• 컴파일 타임에
  • 컴파일 시점에 이미 물리 주소가 결정되는 것
  • 비효율적
• 로드 타임에
  • 메모리에 올라갈 때 물리 주소 결정
  • 컴파일러가 재배치 가능 코드 생성 (relocatable code)
  • 컴파일까지는 논리 주소로 매핑되어있음
• 실행 시작 중간에 (runtime binding)
  • 메모리에 올라갈 때 물리 주소 결정은 동일
  • 실행 도중에 물리 주소가 바뀔 수 있음
  • MMU 지원이 필요함

MMU (Memory Management Unit)

• 논리 주소를 물리 주소로 매핑해주는 하드웨어
• base register, limit register 두개로 주소 변환을 하게 됨
• 시작 위치(base)와 논리 주소를 더해주면 됨
• limit register는 프로그램의 최대 크기를 넘어서는 것을 감지함
• 사용자 프로그램은 논리 주소만을 다루면 됨

Dynamic Loading

• 프로세스 전체를 메모리에 다 올리는 게 아니라 해당 루틴이 불려질 때 load 하는 것
• memory utiliization 향상
• 프로그램 자체에서 구현 가능
• 가상 메모리 개념과는 다른 것 → 가상 메모리는 OS가 알아서 해주는 것, 동적 로딩은 프로그래머가 직접 하는 것

Overlays

• 메모리에 프로세스 중 실제 필요한 정보만을 올림
• 프로세스의 크기가 메모리보다 클 때 유용
• OS 지원 없이 사용자에 의해 구현
• 초창기 메모리가 작았을 때 했던 작업

Swapping

• 프로세스를 일시적으로 메모리에서 backing store로 쫓아내는 것
• 쫓아내는 걸 swap out, 다시 불러오는 것을 swap in
• Backing store : 디스크
• 중기 스케줄러 (swapper)에 의해 swap out 시킬 프로세스 선정
• 컴파일 타임, 로드 타임일 때는 반드시 위치가 정해지므로 swapping이 힘듦 → runtime binding이 필요

Dynamic Linking

• Linking을 실행 시간까지 미루는 기법
• static
  • 라이브러리가 프로그램 실행 파일에 포함
  • 메모리 낭비 ← 동일 라이브러리를 각 프로세스가 메모리에 올리므로
• dynamic
  • 라이브러리 실행 시 연결(link)됨
  • 라이브러리 호출 시 stub에서 루틴 위치 찾음
  • 메모리에 있으면 그 루틴 주소로 가고, 없으면 디스크에서 읽어옴
  • OS 도움 필요

물리적인 메모리의 할당

• 두 영역으로 나눔
  • OS 상주 영역
  • 사용자 프로세스 영역
    • Contiguous Allocation
      • 각 프로세스가 메모리 연속적인 공간에 적재
    • Noncontiguous allocation
      • 하나의 프로세스를 쪼개서 분산시켜 올림

Contiguous Allocation

• 고정 분할
  • 메모리를 미리 나눠놓음
  • 외부 단편화 : 프로그램보다 메모리 조각이 작아 사용 못하는 경우
  • 내부 단편화 : 프로그램이 메모리 조각보다 작아 내부적으로 낭비되는 경우
• 가변 분할
  • 메모리를 미리 나눠놓지 않음
  • 외부 단편화 발생 - 작은 프로세스 수행 후 끝났을 때 공간이 작아 다른 프로그램이 못 들어감
  • Compaction(압축) 필요 → 구멍을 메꾸기 위해 위로 쭉 미는 것
    • 매우 비용이 많이 든다
    • 프로세스 주소가 실행 시간에 동적 재배치 가능한 경우에만 수행 가능
  • 구멍 중에서 어디에 프로세스 할당할 것인가
    • First fit : Size가 n 이상인 것 중 최초로 발견한 곳에 할당
    • Best fit : Size가 n 이상인 것 중 가장 작은 hole에 할당
    • Worst fit : 가장 큰 hole에 할당
  • first fit이 젤 좋음

Noncontiguous Allocation

• Paging
  • 프로그램 구성 공간을 같은 크기로 자름 → page
  • 메모리 공간 또한 같은 크기로 자름 → frame
  • 주소 변환이 복잡해짐
  • 페이지 테이블 사용 → 논리적인 페이지가 실제 물리적 메모리 어디에 위치하는가를 저장
  • 논리 주소의 앞쪽은 페이지 인덱스, 뒤쪽은 오프셋
    • 페이지 인덱스를 프레임 인덱스로 바꾼 뒤 찾음
  • 페이지 테이블은 굉장히 큰데 어디에?
    • 메모리에 집어넣음
    • 그래서 모든 메모리 접근 연산은 2번에 메모리 접근 필요
      • 한번은 페이지 테이블, 한번은 실제 페이지 접근
      • Page-Table Base Register 가 페이지 테이블 가리킴
      • Page-Table Length Register 가 테이블 크기 보관
    • 속도 향상을 위해 TLB라는 일종의 캐시 사용
      • 페이지 테이블에서 빈번히 접근하는 페이지들로 구성
    • TLB 먼저 검색 → 없으면 페이지 테이블 검색
      • TLB 엔트리는 페이지와 프레임의 쌍으로 구성 → fully associative → 전체 검색해야함
    • TLB는 context switch 때 Flush 함
  • 현대 메모리가 매우 커서 페이지 테이블이 너무 큼, 그러나 실제 사용 페이지는 상당히 적음
    • 2 level 페이지 테이블 사용
      • 페이지 테이블의 페이지화
    • Inverted Page Table
      • 시스템 안에 페이지 테이블 하나 존재
      • 엔트리가 물리적인 frame 개수만큼 존재
      • 물리 주소를 보고 논리 주소를 알아내는 방식
      • 결국 페이지 테이블을 다 찾아봐야함
      • 공간을 줄이는 대신 시간 오버헤드가 발생
• Segmentation
  • 프로그램 주소 공간을 의미있는 크기(code, data, stack)로 자름 → segment
  • <segment 번호, offset> 으로 논리 주소 구성
  • 세그먼트 테이블 필요
    • 세그먼트 번호와 함께 최대 길이도 저장해야함
  • Segement-Table Base Register (STBR) : 물리적 메모리에서의 세그먼트 테이블의 위치
  • Segment-Table Length Register (STLR) : 프로그램이 사용하는 세그먼트의 수
  • 중간중간 hole이 발생할 수 있음 ← 균일하지 않으므로
    • first fit, best fit 등 뭔가 필요
    • 의미 단위로 잘라서 공유와 보안에 있어 paging보다 훨씬 효과적임
  • 세그멘테이션이 테이블로 인한 낭비가 적음 → 몇개 없으므로
• Paged Segmentation
  • 세그먼트 테이블 엔트리가 세그먼트의 base address를 가지고 있는 것이 아닌 segment를 구성하는 page table의 base address를 가지고 있음
  • 세그먼트 하나가 여러 페이지로 나눠져서 존재
  • Hole이 생기는 문제 해결
  • 두가지 방법의 장점을 모두 가져감
• 위 세개의 방법 모두 하드웨어 지원이 필요함