운영체제의 역할
- 응용 프로그램이 요청하는 메모리를 허가하고, 분배
- 응용 프로그램이 요청하는 CPU 시간을 제공
- 응용 프로그램이 요청하는 IO Devices 사용을 허가/제어
유닉스 시스템의 호출 인터페이스
- 운영체제 각 기능을 사용할 수 있도록 시스템 콜이라는 명령(함수)을 제공
- API 내부에는 시스템 콜을 호출하는 형태로 만들어짐
프로세스 호출
- 하나의 프로세스가 다른 프로세스의 메모리, 데이터, 함수 호출은 기본적으로 불가능
- 운영체제는 IPC(Inter Process Communication)를 제공함
- 프로세스가 운영체제의 함수를 호출하는 목적
- 시스템 자원 접근
- 운영체제의 함수를 시스템 콜을 불러 서비스
- 주로 시스템 호출을 직접 사용이 아닌 상위 수준의 응용 프로그램 인터페이스(API)를 통해 프로그램에서 액세스
- WIN32 API, POSIX API, JVM용 JAVA API 등
- 응용 프로그램이 하드웨어의 자원을 요청하면 시스템 콜이라는 요청서 제공
- 시스템 콜은 프로그래밍에서 사용하기 복잡하므로 API 형태로 운영체제 기능을 요청할 수 있는 인터페이스 제공(라이브러리 or API)
- 라이브러리나 API를 기반으로 하여 어플리케이션 또는 셸이 해석
운영체제의 모드
커널 모드
- 커널 모드는 프로그램이 구동에 있어 파일 읽기, 파일 쓰기, 출력하는 등 동작 가능한 상태
- 커널의 영역이 기능(CPU 명령어)을 사용자 모드가 사용 가능하게 하는 것
- 프로세스가 하드웨어에 직접 접근해서 필요한 기능을 사용하는 것
사용자 모드
- 응용 프로그램이 동작되는 모드로 하드웨어를 직접 제어 할 수 있는 CPU 명령어 사용 불가능
- 시스템 콜 또한 운영체제가 사용자에게 제공해주는 서비스 중 하나
- 일반적으로 고급언어(C or C++)로 작성
응용프로그램 & OS & 하드웨어의 관계
- 응용 프로그램이 요청하는 메모리를 허가하고 분배
- 요청하는 CPU 시간을 제공
- IO Devices 사용 허가/제어
운영체제의 사용자 인터페이스 제공
- Shell: 사용자가 운영체제 기능과 서비스를 조작할 수 있도록 인터페이스를 제공하는 프로그램
- 터미널 환경(CLI), GUI 환경 두 종류로 분류
운영체제의 응용 프로그램을 위한 인터페이스 제공
- API(Application Programming Interface)
- 함수로 제공
- open(), read(), write() 등
- 라이브러리 형태로 제공
- C library
UNIX 메모리 관리
- 유닉스는 처음 단일 사용자 위해 개발, 나중에는 다중 사용자 환경에 적합하도록 발전
- 다중 프로그래밍 유닉스에서는 메모리 관리 방법으로 대치(swap)나 페이징 사용
- 메모리 관리자는 각 프로세스를 메모리에 저장하는 동안 중첩되지 않도록 보호
- 메모리에 상주하는 커널은 여러 프로세스가 메모리에 동시에 있도록 메모리 경계 설정
대치
- 유닉스는 메인 메모리와 대치장치 사이에 전체 프로세스 전송
- 대치 구현 용이, 시스템 오버헤드 적음
- 메모리의 외부 단편화 문제가 심각
- 커널이 단편화를 고려하지 않고 대치장치에 연속 공간 할당을 함
- 커널은 파일 시스템의 자유 공간을 슈퍼 블록에서 액세스되는 자유 블록 연결 리스트로 관리
- 대치장치의 자유 공간은 맵 테이블에 유지
- 유닉스에서 메모리와 대치 공간의 할당은 최초 적합 전략 이용
- 하나의 맵은 배열로 할당 가능한 자원 주소와 그 위치에 있는 사용 가능 자원 수로 구성
- 커널은 한 프로세스의 가상 주소 공간을 대치장치에 사용 불필요
- 프로세스에 배정된 물리적 주소를 대치장치에 복사
- 배정되지 않은 가상 주소 무시
- 커널은 가상 주소 위치에 맞게 설정된 물리적 주소에서 데이터를 읽어 들여 데이터 버퍼에서 물리적 주소로 추가 복사 않음
- 대치는 순환 할당 알고리즘 사용
- 작업의 시간 할당량을 종료하거나 입출력 인터럽트 발생하면 대기 큐의 다른 작업 공간 만들려고 전체 작업을 보조기억장치로 대치
- 프로세스 수가 상대적으로 적을 때는 무리 없이 수행
- 잦은 대치로 전송량이 증가하면 시스템 속도 감소
페이징
- 페이징을 사용하면 메모리의 외부 단편화 해결 할 수 있지만, 내부 단편화 발생
- 복잡한 하드웨어 구성과 시스템 오버헤드의 증가
- 작업 부하가 크면 스래싱 현상 야기
- 사용자 프로세스와 디스크 입출력 위해 효과적 메모리 관리
- 페이징 방법에 사용하는 페이지 프레임 데이터 테이블
| 페이지 프레임 데이터 테이블 | |
| 페이지 상태 | 프레임을 사용할 수 있는지 또는 연관된 페이지가 있는지 여부를 나타냄 |
| e.g. 프로세스의 할당 여부를 나타냄 | |
| 참조 횟수 | 페이지에 참조한 프로세스 수를 나타냄 |
| 프로세스들이 동일한 물리적 페이지를 공유할 수 있음 | |
| 논리장치 | 페이지의 물리적 사본이 들어 있는 디스크의 장치 번호를 나타냄 |
| 블록 번호 | 페이지 데이터가 있는 디스크의 블록 번호를 나타냄 |
| 페이지 프레임 데이터 포인터 |
프레임 테이블로 빈 프레임의 단일 링크 리스트를 스레드로 사용하는 포인터 필드 |
| 빈 페이지이면 이 포인트는 다음 빈 페이지를 가리킴 | |
| 빈 리스트 할당에 유용 | |
- 페이지 대치 알고리즘은 실행 중인 프로토콜 지원
- 사용 가능한 프레임을 충분한 유지 위해 최근 최소 사용 알고리즘 사용
- 최근에는 수정된 시계 페이지 대치 알고리즘 사용
- 페이징 구현하여 프로세스의 전체 가상 주소 공간을 메모리에 적재 안해도 수행 가능
- 프로세스의 가상 주소 크기가 시스템에서 이용 가능한 물리적 주소의 양 초과사용이 가능
- 프로세스는 제한된 지역을 중심으로 참조하는 지역성 원리 적용
- 작업 집합: 프로세스가 참조한 페이지 집합
- 전체 프로세스의 작은 부분으로 대치 시스템보다 많은 프로세스를 동시에 메인 메모리에 적재, 대치량과 시스템의 스래싱 현상 감소
프로세스의 작업 집합
- 윈도우 크기가 클수록 작업 집합이 크며 프로세스의 페이지 부재 덜 발생
- 페이지 참조의 순서를 기억하는 비용이 많이 들어 순수한 작업 집합 모델을 구현하는 것은 비현실적임
- 시스템은 프로세스가 페이지 액세스할 때마다 참조 비트 설정
- 메모리 참조 주기적으로 샘플링 개략적인 작업 집합 모델 구현
- 어떤 페이지를 최근에 참조했다면 해당 페이지는 작업 집합의 일부분이 됨
- 아니면 대치될 자격이 생길 때까지 메모리에서 대기
UNIX 파일 시스템
- 연결 리스트 형태의 디스크 블록: 디스크 블록은 자유 디스크 블록의 번호 포함하는 배열 형태, 이 중한 항목은 다음 디스크 블록의 번호 가리킴
유닉스 디스크 블록의 구조
| 부트 블록 | 파일 시스템에 유닉스 커널을 적재시키는 프로그램을 포함 |
| 이런 프로그램을 부트 스트랩(bootstrap) 또는 부트 로더(boot loader)라고 함 | |
| 데이터 블록 | 일반 파일이나 디렉터리 파일의 내용 들어있음 |
| 슈퍼 블록 |
파일 시스템을 관리하는 정보 |
| 파일 시스템에 있는 블록의 총 수 | |
| 파일 시스템에 있는 자유 i 노드의 리스트와 i 노드 수 | |
| 파일 시스템에서 이용 가능한 자유 블록 리스트(비트맵) | |
| 바이트 단위로 된 블록의 크기 | |
| 자유 블록 수, 사용 중인 블록 수, 파일 수 | |
| 자유 i 노드 리스트에서 다음 자유 i 노드를 가리키는 인덱스 |
연속 파일 할당과 자유 공간의 단편화
- 쓰레기 수집으로 해결 가능하나, 시스템의 처리 능력 떨어뜨림
- 파일에 디스크 블록을 하나씩 할당하여 블록들이 파일 시스템의 여러 곳에 분산함으로써 융통성 높임
- 단점은 데이터를 찾는 알고리즘을 복잡하게 함
- i 노드 리스트에 파일의 데이터가 들어 있는 블록 번호 모두 담을 수 있지만, 이런 선형 목록은 관리 곤란
유닉스의 시스템 파일 테이블
- 파일을 열 때 참조되는 시스템 호출은 파일 디스크립터를 인자로 전달하여 파일을 지정
- 파일 디스크립터: 현재 프로세스가 참조하는 열린 파일의 테이블을 인덱스로 찾는 것
- 테이블의 각 항목에는 파일 구조 가리키는 포인터 있음
