운영체제

16) segmentation

이전까지 프로세스 전체의 주소공간을 메모리에 올리는 것을 가정했다.
이러한 경우 스택과 힙의 free space가 낭비된다.
또 주소 공간이 실제 메모리보다 큰 경우도 곤란하다.

기존 단일 base bound의 문제점

1. 메모리 낭비
   • free 공간이 실제 메모리에서 낭비된다.
2. 큰 주소공간에 대해서
   • 실제 메모리보다 큰 용량의 주소 공간은 지원할 수 없다.
3. 중복되는 코드 부분
   • 코드부분이 중복이 되면 메모리가 낭비가 된다.

세그멘테이션으로 위의 문제를 해결할 수 있다.

세그멘테이션

주소 공간을 조각 내 각 세그먼트들을 독립적으로 실제 메모리에 매핑한다.

• 코드 조각, 힙 조각, 스택 조각

• 더이상 메모리 낭비를 하지 않음

  • 사용되지 않는 free 주소 공간이 물리 메모리를 차지하는 것을 방지 가능

• 큰 주소공간도 지원함

  • 전체 주소공간 할당하지 않음, 조각 내서..

• code sharing 지원

세그멘트 - 특정 길이를 가지는 연속적인 주소 공간 (code, heap, stack)

• 각 세그먼트는 실제 메모리의 각 다른 위치에 배치할 수 있다.
  • base bound가 각 세그먼트 마다 존재! (PCB가 관리)
    • MMU에는 베이스 바운드 레지스터의 set들이 있다.

세그먼트 종류 파악

explict 접근

• 가상주소의 최상위 비트를 세그먼트 종류를 나타내는데 사용
  • 3개의 세그먼트(코드,스택,힙) => 2비트 사용
• 가상 14bit 주소 = 실제는 2^14 바이트

계산법

• 가상주소 = 세그먼트 id + offset
• 세그먼트 id를 보고 해당 세그먼트의 base + offset을 통해 주소 변환

실제 코드에서 판단하는 법

1. 세그먼트 판단 비트를 알기위해 해당 비트 마스크를 씌워 오른쪽 쉬프트를 통해 값 판별
2. offset은 위의 마스크 반대 마스크를 씌워 판별
3. 폴트가 일어나는지 계산 후 주소 계산

문제점 가상 주소공간의 활용도 제한

• 2비트를 사용하는데 3개의 세그먼트만 있으니 1개의 공간이 남는다.

ex

가상 주소 14비트 = 실제 메모리 크기: 2^14 바이트 = 16kb
이 때 2비트가 세그먼트 판별 비트 그러면 각 세그멘트 당 4kb씩 할당 가능
그런데 3개의 세그먼트 판별비트로 인한 주소 사용가능 하나가 남음!!!

하나의 비트로 판단하는 방법도

• 코드와 힙을 하나의 세그멘트에 저장하고 세그멘트 선택을 1비트만 사용
  • 모든 공간 활용 가능

다른 접근

• 하드드웨어적으로, 주소가 어떻게 형성되었는지 관찰해 세그먼트 파악
  • PC로부터 생성: 코드 세그먼트
  • 스택, 베이스 포인터에 기반: 스택 세그먼트
  • 나머지: 힙 세그먼트

스택

• 스택은 다른 세그멘트들과 달리 낮은 주소로 확장됨(backward)

다른 방식의 주소 변환이 필요

추가적 하드웨어 필요

• flag를 둬서 어느 방향으로 세그멘트가 커지는지 체크함
• ex) 1: 양수 2: 음수

스택 주소 변환 방법

• 스택 세그멘트의 베이스 레지스터는 제일 높은 주소를 가리킨다.
  • offset은 음수여야함!
    • 2의 보수 활용
    1. 세그멘트로 스택 판별
    2. offset 음수 전환
    3. 바운드체크
    4. 베이스랑 계산

code sharing

• 메모리를 절약하기 위해 주소공간들끼리 특정 메모리 세그멘트를 공유하는 것이 유용
  • code sharing
  • 추가적 하드웨어의 지원이 필요
    • protection bit
• 공유되는 세그멘트는 누군가 함부러 수정하면 안되니 protection bit을 둬 보호한다.
  • read, write, execute에 대한 권한을 줌
• 다수의 프로세스가 코드 세그멘트를 공유한다.
  • 코드 세그멘트는 write가 허용되면 안된다.

세그멘트의 세분화

• 대단위(coarse-grained)
  • 소수의 세그멘트(코드,스택,힙)으로
• 소단위(fine-grained)
  • 초기에 세그멘트를 많이 쪼개
    • 세그멘트 테이블을 이용해 세그멘트의 정보를 관리

OS 지원

context switch

• 세그멘트 레지스터(베이스 바운드 레지스터 쌍)들은 저장되어야되고 복구 되어야한다.
  • PCB! 프로세스에 해당하는 세그멘트 테이블을 교체해야한다.
• 각 프로세스는 자신의 가상주소를 갖기 때문에, 운영체제는 올바르게 레지스터를 관리해야한다.

세그멘트 크기 변경

• malloc을 통해 힙 크기를 늘리면??
• 힙을 확장하기위해 sbrk() 시스템 콜을 호출

미 사용중인 실제 메모리 공간 관리

• OS는 실제 공간에 세그멘트들을 위한 여유 공간을 찾아야한다.

외부 단편화 external fragmentation

• 작은 공간들은 새로운 세그멘트에 할당하기 어렵다.
  • 전체 여유공간 24kb, but 연속적 X - OS는 20kb인 세그멘트를 할당 못함..

compaction

• 기존 세그멘트를 정리해 물리 메모리를 압축해 연속적인 여유 공간을 만든다.
• But 성능 저하가 심함
  • 진행중인 프로세스를 멈추고
  • 데이터를 복사하고
  • 세그멘트 레지스터(베이스 바운드) 값들을 바꿔야하기 때문

paging

• 외부 단편화를 고정된 세그멘트 크기를 이용해 없앰
  • 이전에는 세그멘트 크기가 가지각색이니 공간이 남아도 할당 못하는 경우가 있었음
• 그럼 내부 단편화는??

요약

• 세그멘테이션은 실제 메모리 할당에 효과적이다
  • 메모리를 낭비하지 않는다
  • 큰 주소 공간을 할당할 수 있다
  • code sharing이 지원된다.
• 세그멘테이션의 문제점
  • 외부단편화
    • 해결법: 페이징