Jun 개발노트

운영체제 10

March 14, 2020

프레임할당

  • 정적할당 (비효율적이다)

    • 균등할당 : 크기를 고려하지 않고 프로세스당 동일한 프레임를 할당
    • 비례할당 : 전체 프레임수를 해당 프로세스의 크기 별로 비례하여 할당
  • 동적할당 (실제로 사용)

    • 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 페이지 폴트
  3. Page fault 발생 비율의 상한/하한선을 정한다

    • 기준 : OS내에 페이지 fault를 감시하는 프로그램 있음
  4. 상한선(upper Bound) 초과 프로세스에 더 많은 프레임 할당

    • 이유 : 속도 향상을 위해 프레임 더 할당
  5. 하한선(lower Bound) 이하 프로세스에 프레임 회수

    • 이유 : 프레임을 회수하여 다른 프로세스를 실행시켜 효율성 증대

페이지 크기

  • 주제 : 페이지는 크기는 작은것? 큰것? 어떤게 좋을까?
  • 페이지 크기 영향

    1. 내부 단편화
    2. 프레임이 10바이트 페이지 5바이트라면 5바이트가 남는다. 다른곳에서 사용못한다
    3. 효율성이 증대를 위해 페이지 크기가 작은게 좋다
    4. Page-in / out 시간
    5. 하드디스크에서 페이지를 읽어오는 시간(해당 페이지를 찾는 작업)은 크기에 상관없이 동일하다.

      • 찾는 작업 : 디스크를 찾기 위해 헤드 이동(가장 큼) -> 디스크가 다시 회전 -> 디스크에서 파일 읽기
    6. 하지만, 한번에 큰 페이지를 읽어오는게 페이지 fault가 일어나는 확률이 적다
    7. 페이지 테이블 크기
    8. 페이지 테이블은 SRAM으로 제작하기 때문에 비용이 크다
    9. 페이지 테이블을 작게 만드는게 비용이 적기 때문에 페이지 크기를 크게
    10. Memory resolution
    11. 요구하는 페이지의 정확도!! 정확도가 높으려면 페이지가 작아야 한다
    12. 페이지가 크다면 원하는 않는 내용도 옴
    13. Page faults 발생 확률
    14. CPU가 메모리를 읽는 작업은 지역성을 가진다. 100번을 읽으면 다음 작업은 100번 주변을 읽는다
    15. 이러한 지역성때문에 페이지 크기를 크게 하여 페이지 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. 연속할당
  2. 각 파일에 대해 디스크 상의 연속된 블록을 할당
  3. 사용처 : VOD, 동영상, 음악 파일에 적합
  4. 장점

    • 디스크 헤더는 가만히 있고, 디스크가 계속해서 돌면서 다음 블록을 읽을 수 있기떄문에 빠른 I/O성능
    • 순서적으로 읽을수 있다(sequential access)
    • 특정부분을 바로 읽을수 있다(direct access) : 시작위치를 알면 순서를 알기 때문에 바로 읽을 수 있다
  5. 단점

    • 파일이 삭제되면 동일한 크기나, 작은 크기의 파일만이 들어올수 있다 : 외부단편화 발생 => 효율성 저하
    • 파일의 크기는 계속해서 변하기 떄문에, 해당 hole을 배치 여부를 알 수 없다.
  6. 연결할당
  7. 자료구조의 linked list와 비슷하다
  8. 각 블록에 포인터를 저장하여 다음 블록을 가르킨다.
  9. 장점

    • 파일이 커져도 포인터를 통해 연결해서 : 외부단편화 없음
  10. 단점

    • 포인터 저장을 위해 4바이트 손실
    • 순서대로 읽을 수 없다.(linked list의 단점 : 읽기가 느리고, 수정/삭제/삽입에는 좋다)
    • 낮은 신뢰성 : 포인터가 끊어지면 접근 불가
    • 느린 속도 : 지속적인 헤더가 움직임(파일을 찾는 시간중 제일 큰 시간 차지)으로 인해 로딩시간 오래 걸린다.
  11. 개선 : FAT(file allocation table) 파일 시스템

    • 전체 파일들의 포인트들만 모은 테이블을 별도의 블록으로 저장
    • Direct access 도 가능!,
    • FAT는 부팅시일반적으로 메모리 캐싱
    • FAT 손실시 복구 위해 이중 저장
  12. 색인할당
  13. 파일 당 한개의 인덱스 블록(포인터의 모음)
  14. 디텍토리는 인덱스 블록을 가르킴
  15. 장점

    • Direct access 가능
    • 외부 단편화 없음
  16. 단점

    • 인덱스 블록 할당에 따른 저장 공간 손실(데이터가 1kb 작아도 무조건 인덱스 블록 생성)
    • 파일의 최대 크기

      • 예제: 1블록 = 512바이트 = 4바이트 x 128개 인덱스 (128 * 512바이트 = 64KB)
      • 예제: 1블록 = 1KB = 4바이트 x 256개 인덱스 (256 * 1KB = 256KB) – 해결 방법
      • Linked : 마지막 포인터를 또 다른 인덱스 블록을 가르킨다.
      • Multilevel index : 포인터 마다 인덱스 블록을 가르킨다
      • Combined : linked + multilevel index => 필요에 따라 블록을 가르키거나 인덱스 블록을 가르킴

Written by Junho You 배운것을 기록하자