강의를 들으면서 이해하고 빠르게 적어서 빠지거나 부족한 내용이 있습니다. 전체적으로 이러한 강의 형식임을 확인해보셨으면 좋겠습니다.
캐시에 대해
캐시에 사이즈가 프로그램을 빠르게 돌리는데 도움이 크다. 캐시에 도움에 따라 첫번째 돌리는 프로그램 보다 두번째 돌리는 프로그램이 더 빠르다.
OS는 소프트웨어를 돌릴 떄 하드웨어가 어떻게 돌아가는지 몰라도 일관된 방식에 따라 작동시킬수 있다. 또한 스케줄러에 따라 효과적으로 프로그램을 관리할 수 있게 하기 위해 사용합니다.
추상화가 무엇인가?
→ 복잡한 걸 단순하게 생각하기 위해, 무엇을 만드는 과정들을 사용자가 이해하기 쉽도록 중요하지 않은 사항들을 지워버리고 생각하는 것이다.
OS 디자이너가 생각한 것?
- 프로그래머는 하드웨어에 대해 디테일하게 알고 싶지 않다. 쉽게 프로그램하고 싶다.
- 하드웨어 리소스를 효과적으로 쓰고 싶다. 애플리케이션을 여러개 돌리고 싶다.(실행단위가 분리되어 있어야한다)
- 다른 애플리케이션이 다른 애플리케이션에 영향을 주지 않고 보호되어야한다. (유닛이 보호되고 분리되어야한다)
프로세스: 하나의 애플리케이션을 컴퓨터의 리소스를 사용하기 위해 사용. (Abstraction 제공)
OS에 대한 API는 시스템 콜이라고 부른다.
프로세스가 실제 메모리에 들어가기 위해서 address translation mechanism을 통해 pyhsical address를 지정하여 들어간다.
실제 pyhsical address를 map하는 요소
- 세그멘테이션
- paging
- 세그멘테이션 페이징
exception, fault, abort, interrupt → 하드웨어적으로 영향을 주는 것임
페이징에 관여하는 요소
- TLB 캐싱
- page 넘버
- frame 넘버
물리적 메모리를 할당시?
페이지 수요 → 애플리케이션이 먼저 할당되지 않은 물리적 메모리에 액세스합니다.
초기화를 하려는 이유?
다른 애플리케이션이 개입이 되어 액세스하면 문제가 생길 수 있기때문이다. (마치 통신하는 것과 같다)
10분간 휴식
페이징 폴트 핸들링
지금까지 메모리를 할당하는 경우만 이야기 했다.
두 타입의 메모리: 메인 메모리와 디스크 (anonymous, file- backed)
가상메모리를 쓰는 이유: 실제 4기가인 램밖에 없는데, paging을 통해 더 많은 양의 메모리를 프로세스가 사용할 수 있다.
DMA: 기존의 방식으로 CPU의 개입으로 하드디스크와 메모리의 속도 차이가 크니, 디스크에 있는 메모리에 직접 접근하므로서 속도를 올리는 것.
핸들링 I/O 이벤트
인터럽트와 폴링을 통해 시스템이 장치와 통신하고 제어합니다. 대부분의 실제 시스템(특히 하드웨어에 가까운 곳)은 효율성 때문에 인터럽트를 선호합니다.
인터럽트 핸들링도중이 또 인터럽트를 가질수 있으니 무시하여야 원자적으로 실행할 수 있다.
인터럽트
- 디바이스 시그널을 CPU가 집중할 필요가 있다.
- 하드웨어: 인터럽트 요청 라인이 있다.
- 인터럽트 핸들러로 인터럽트를 핸들링한다.
- 인터럽트는 얼마의 시간이 필요하다.
폴링
- CPU continuously checks if the device needs attention
- software plicy
DMA
- … 했는데 쓰지 못했다.
파일
파일: 스토리지의 logical unit을 의미
데이터 위치는 identified by offset.
파일의 위치를 physical 스토리지로 바꾸는는 것 → 파일 시스템(NTFS, FAT32, APFS, EXT)
logical addr. → physical addr.
filename, offset → location in storage
하드웨어를 인덱싱하는게 없는 이유?
스토리지가 너무 느려서 그걸 하드웨어가 해봤자 크게 차이가 없기 떄문에 그냥 소프트웨어로 만들어 버렸다.
피지컬 블록은 언제 할당되는가?
실제 메모리에 있는 내용과 동기화할 때만 쓴다.
DRAM과 스토리지의 data와 meta data가 일관성이 맞아야한다. atomicity와 durability 조건을 만족시켜야한다. 그러나 리눅스와 유닉스는 보증하지 않는다. 그래서 소프트웨어 개발자가 소프트웨어 내에서 보장해야한다. 그래서 파일 시스템을 잘 안쓰고 DBMS를 쓴다.
비원자성 업데이트
한 블럭은 완전히 써지거나 안써져야한다. 이미지 파일이 써지다 말면, 중간의 이미지가 깨질 수 있다.
그냥 write를 두번 연속으로 하면 레코딩하는 과정에서 크래시 될 수 있는데, 이러한 현상을 막기위해 각 write마다 fsync를 통해 스토리지와 동기화를 한다.
그러나 이러한 방식도 문제가 있을수 있다. /a/log 만 반영되면 문제가 생길 수 있어, /a/ 단독도 fsync로 동기화 해줘야한다. 디렉터리도 동기화해야한다.
