운영체제 10

프레임할당

• 정적할당 (비효율적이다)
  • 균등할당 : 크기를 고려하지 않고 프로세스당 동일한 프레임를 할당
  • 비례할당 : 전체 프레임수를 해당 프로세스의 크기 별로 비례하여 할당
• 동적할당 (실제로 사용)
  • Working set model
  • Page faults frequency
  • etc

동적할당

1. Working set model

   • Locality : 과거의 기록으로 몇개의 페이지가 뭉쳐져 잇는가
   • Working set : 과거의 기록으로 통계를 내어 미래의 프레임 크기
   • Working set window : Working set을 구하려면 과거의 기록을 일정기간 정해서 통계를 구해야함 => 구간 (형태가 창문같다)
   • Working set 크기만큼 프레임 할당
     • 이유 : 너무 많은 면 메모리가 남아 단편화 발생, 너무 적으면 메모리가 효율성이 없음

2. Page faults frequency

• Page fault 발생 비율의 상한/하한선을 정한다
  • 기준 : OS내에 페이지 fault를 감시하는 프로그램 있음
• 상한선(upper Bound) 초과 프로세스에 더 많은 프레임 할당
  • 이유 : 속도 향상을 위해 프레임 더 할당
• 하한선(lower Bound) 이하 프로세스에 프레임 회수
  • 이유 : 프레임을 회수하여 다른 프로세스를 실행시켜 효율성 증대

페이지 크기

• 주제 : 페이지는 크기는 작은것? 큰것? 어떤게 좋을까?
• 페이지 크기 영향
  1. 내부 단편화
     • 프레임이 10바이트 페이지 5바이트라면 5바이트가 남는다. 다른곳에서 사용못한다
     • 효율성이 증대를 위해 페이지 크기가 작은게 좋다
  2. Page-in / out 시간
     • 하드디스크에서 페이지를 읽어오는 시간(해당 페이지를 찾는 작업)은 크기에 상관없이 동일하다.
       • 찾는 작업 : 디스크를 찾기 위해 헤드 이동(가장 큼) -> 디스크가 다시 회전 -> 디스크에서 파일 읽기
     • 하지만, 한번에 큰 페이지를 읽어오는게 페이지 fault가 일어나는 확률이 적다
  3. 페이지 테이블 크기
     • 페이지 테이블은 SRAM으로 제작하기 때문에 비용이 크다
     • 페이지 테이블을 작게 만드는게 비용이 적기 때문에 페이지 크기를 크게
  4. Memory resolution
     • 요구하는 페이지의 정확도!! 정확도가 높으려면 페이지가 작아야 한다
     • 페이지가 크다면 원하는 않는 내용도 옴
  5. Page faults 발생 확률
     • CPU가 메모리를 읽는 작업은 지역성을 가진다. 100번을 읽으면 다음 작업은 100번 주변을 읽는다
     • 이러한 지역성때문에 페이지 크기를 크게 하여 페이지 fault를 적게 만든다.
• 현재 : 메모리가 점점 커지므로 페이지의 크기도 점점 커지고 있다
• 기술동향
  • 원래는 별도의 chip으로 구성되어 있어야 하지만, 메모리 기술이 발달하면서 cpu에 내장됨

파일할당

• 컴퓨터 시스템 자원관리
  • CPU : 프로세스 관리(CPU 스케줄링, 프로세스 동기화)
  • 주기억장치 : 메인 메모리 관리(페이징, 가상 메모리)
  • 보조기억장치 : 파일 시스템
• 보조기억장치(하드디스크)
  • 하드디스크 : track, sector로 구성
  • sector size = 512 bytes / 여러개의 sector => Block size(OS설계자 마음)
  • 블록단위의 읽기 / 쓰기 => block device
    • 메모장에 'A'라는 글자만 저장하면 디스크에서는 블록단위로 저장되기 때문에 1byte가 아니라 4byte가 된다(OS설계자 마음)
  • 디스크 => pool of free Blocks => 블록으로 가득 찬 pool

파일할당을 어떻게 할것인가?

1. 연속할당

• 각 파일에 대해 디스크 상의 연속된 블록을 할당
• 사용처 : VOD, 동영상, 음악 파일에 적합
• 장점
  • 디스크 헤더는 가만히 있고, 디스크가 계속해서 돌면서 다음 블록을 읽을 수 있기떄문에 빠른 I/O성능
  • 순서적으로 읽을수 있다(sequential access)
  • 특정부분을 바로 읽을수 있다(direct access) : 시작위치를 알면 순서를 알기 때문에 바로 읽을 수 있다
• 단점
  • 파일이 삭제되면 동일한 크기나, 작은 크기의 파일만이 들어올수 있다 : 외부단편화 발생 => 효율성 저하
  • 파일의 크기는 계속해서 변하기 떄문에, 해당 hole을 배치 여부를 알 수 없다.

2. 연결할당

• 자료구조의 linked list와 비슷하다
• 각 블록에 포인터를 저장하여 다음 블록을 가르킨다.
• 장점
  • 파일이 커져도 포인터를 통해 연결해서 : 외부단편화 없음
• 단점
  • 포인터 저장을 위해 4바이트 손실
  • 순서대로 읽을 수 없다.(linked list의 단점 : 읽기가 느리고, 수정/삭제/삽입에는 좋다)
  • 낮은 신뢰성 : 포인터가 끊어지면 접근 불가
  • 느린 속도 : 지속적인 헤더가 움직임(파일을 찾는 시간중 제일 큰 시간 차지)으로 인해 로딩시간 오래 걸린다.
• 개선 : FAT(file allocation table) 파일 시스템
  • 전체 파일들의 포인트들만 모은 테이블을 별도의 블록으로 저장
  • Direct access 도 가능!,
  • FAT는 부팅시일반적으로 메모리 캐싱
  • FAT 손실시 복구 위해 이중 저장

3. 색인할당

• 파일 당 한개의 인덱스 블록(포인터의 모음)
• 디텍토리는 인덱스 블록을 가르킴
• 장점
  • Direct access 가능
  • 외부 단편화 없음
• 단점
  • 인덱스 블록 할당에 따른 저장 공간 손실(데이터가 1kb 작아도 무조건 인덱스 블록 생성)
  • 파일의 최대 크기
    • 예제: 1블록 = 512바이트 = 4바이트 x 128개 인덱스 (128 * 512바이트 = 64KB)
    • 예제: 1블록 = 1KB = 4바이트 x 256개 인덱스 (256 * 1KB = 256KB) – 해결 방법
      • Linked : 마지막 포인터를 또 다른 인덱스 블록을 가르킨다.
      • Multilevel index : 포인터 마다 인덱스 블록을 가르킨다
      • Combined : linked + multilevel index => 필요에 따라 블록을 가르키거나 인덱스 블록을 가르킴