기침이 아직 좀 나오긴하지만 오늘부터 강의실 다시 출석
09:40 입실
실제 메모리의 제한은 넘어 메모리와 디스크를 활용해 논리적인 주소 공간을 제공하는 것
가상 메모리를 관리하는 기법에 페이징과 세그멘테이션이 있음.
프레임은 물리 메모리에 프레임 단위로 순서대로 부여되어 있는 것!
그래서 논리 주소에 매핑되는 프레임 주소를 곱한다음 옵셋을 더하는 간단한 방식으로 실제 메모리 주소를 유추할 수 있음.
32비트 시스템에서는 한 번에 32비트(4바이트)를 전송할 수 있는 메모리 버스 대역을 지닌다.
페이징 기법에 사용되는 자료구조
프로세스의 페이지 정보를 저장하는 테이블
하나의 프로세스는 하나의 페이지 테이블을 가짐.
색인과 내용으로 구성된다.
페이지 테이블의 레코드
배열 기반 선형 페이지 테이블은 메모리를 과도하게 차지한다.
하지만 이 경우 내부 단편화 야기
참고로 멀티 페이지라는 개념도 있음. 일부 프로세스는 완전 대형 페이지(4MB 등)에 할당하기도 함.
논리 주소 -> 물리 주소 변환은 복잡한 연산이 필요한 게 아니다. 그냥 일대일로 매핑해서 치환하는 것!
페이지 번호를 프레임 번호로 바꿔서 옵셋 값을 더해주면 되는 것!
(OS 교재)
페이징의 단점은 주소 변환을 위해 매번 메모리에 상주하는 페이지 테이블을 읽어야 한다는 점
이는 엄청난 오버헤드를 발생시킨다.
그럼 주소 변환 속도를 빠르게 해야 한다. 이때 TLB 하드웨어를 쓸 수 있다.
보통 소프트웨어적으로 속도가 느려지면 하드웨어로 해결할 수 있음..
TLB는 MMU의 일부이며, 자주 참조되는 가상주소-물리주소 변환 정보를 저장하는 하드웨어 캐시!
따라서 '버퍼' 보다는 '캐시'가 더 적합한 명칭임.
버퍼에 정보가 있으면 TLB 히트, 없으면 TLB 미스
페이지 테이블 전체가 아닌 페이지 테이블 엔트리가 산발적으로 적재
TLB 미스 시 CICS는 하드웨어가 처리, RICS는 소프트웨어 관리 TLB를 사용
RICS에서는 exception 시그널 발생 -> trap 핸들러 실행 -> TLB 갱신 -> TLB 히트
일반적인 TLBsms 32, 64, 128개의 엔트리를 가진다.
VPN | PFN | 다른 비트틀
형태로 저장됨.
프로세스가 바뀌면 같은 논리 주소에 따라 다른 물리 주소가 매핑되어야 한다.
문맥 교환 시 새로운 프로세스는 이전 프로세스가 사용한 TLB 정보는 의미 없다.
대표적으로 LRU가 있음.(최저 사용 빈도)
프로세스가 접근하려는 가상 메모리 주소에 해당하는 데이터가 물리적 메모리에 없을 때 발생하는 이벤트
데이터가 필요할 때만 물리적 메모리로 로드하는 요구 페이징 방식의 핵심 매커니즘
데이터, 또는 객체가 실제로 필요할 때까지 로드를 지연
<img src="image2.jpg" alt="Lazy Loading 이미지" loading="lazy">
어떤 페이지를 내보낼까?
좋은 페이지 교체 알고리즘은 페이지 폴트가 가장 적게 발생해야 한다.
가장 오래 전 로드된 페이지 먼저 제거
사용 빈도가 가장 낮은 페이지 제거
(최적 페이지 교체)
미래에 가장 오랫동안 사용되지 않은 페이지 제거
미래 예측 불가로 구현 불가. 벤치마킹으로 활용
과거를 비추어 봤을 때 가장 오랫동안 사용되지 않은 페이지 제거
(시간 지역성?)
각 페이지에 '사용됨' 플래그 설정하고, 플래그가 클리어된 첫 번째 페이지 교체
LRU 정책 모방
https://www.youtube.com/watch?v=nF26uioM6zU&t=1146s
시스템의 대부분의 시간이 페이지 교체 작업에 소비되어 실제 유용한 작업을 거의 수행하지 못하는 상태를 말합니다. 즉, 물리 메모리가 부족하여 빈번한 페이지 교체가 발생하고, 이로 인해 시스템 성능이 현저히 저하되는 현상
스레싱은 프로세스들이 너무 많은 메모리를 동시에 요구할 때 발생
즉, 멀티프로세싱이 무한대로 효율적인 건 아님!
페이지는 두 종류가 있다.
1. 익명 페이지: 파일로부터 매핑되지 않고 커널로부터 할당된 페이지
2. 파일 기반 페이지: 파일로부터 매핑된 페이지
프로세스 전체 주소 공간을 페이지로 나누는 건 페이지 테이블이 과도하게 커지는 결과
그래서 논리적인 세그멘테이션 단위로 각각 별도의 페이지 테이블을 구성
이렇게 하면 페이지 테이블 크기를 줄일 수 있음!
세그멘트마다 바운드 레지스터가 따로 존재
페이지 디렉터리 -> 페이지
이건 TBL 미스가 발생하면 메모리에 두 번 이상 접근해야 한다.
(디렉터리와 페이지, 단계가 맞아지면 접근 횟수 많아짐)
대신 실제 사용되는 영역에 대해서만 디렉터리로 테이블을 구성하므로,
필요 없는 주소 공간은 테이블로 관리하지 않아도 된다.
20비트 전체를 다 테이블로 쓰는 게 아니라 10비트씩 순차적으로 테이블을 생성해 나가는 방식. 메모리 공간을 절약할 수 있음.
논리 주소는 page number와 page offset의 결합이다.
32비트 기준 페이지 크기가 4kb일 때 하위 12비트가 오프셋,
나머지 상위 20비트가 페이지 넘버가 된다.
페이지 넘버는 일정 구간으로 잘라서 관리된다.
64비트에서는 페이지 크기가 4kb이면 이론적으로 52비트를 페이지 번호로 쓸 수 있다.
하지만 현재 운영체제와 프로세서는 일반적으로 48비트 또는 그 이하만 주소 공간으로 쓴다.
그 이유는?
1. 2^48은 256TB로 메모리 주소 공간으로 쓰기에는 충분함.
2. 비트를 남겨두어서 미래 확장성에 대비한다.
3. 주소 공간이 너무 커지면 페이지 테이블 같은 메모리 관리 구조 크기가 너무 커진다.
4. 하드웨어 관리에 복잡해진다.(MMU, TLB 등)
5. 주소 공간이 크면 하드웨어 자원과 전력이 필요하다.
디스크 상의 파일이나 데이터에 직접적으로 매핑되지 않는 메모리 페이지
힙을 거치지 않고 할당받은 메모리
0으로 초기화된 값을 가지고 있음.
malloc등으로 동적 할당 시 생성됨.
mmap 시스템 호출을 사용하여 파일이 아닌 메모리를 할당할 때 Anonymous Page가 생성
'Anonymous Page'라는 용어는 페이지가 파일 시스템에 저장된 특정 파일에 직접적으로 매핑되지 않는다는 사실을 나타냄.
익명 페이지의 반대 개념
여기서 파일은 디스크 상에 존재하는 실행 파일, 라이브러리, 데이터 파일을 의미
가상 메모리 페이지가 파일 시스템의 특정 파일과 매핑된 페이지
파일의 데이터를 메모리에 반영
mmap 호출로 파일을 메모리에 매핑할 때 사용
이 페이지를 읽거나 수정할 때 변경 사항이 파일에 반영될 수도 있음.
왜냐면 페이지가 파일과 매핑되어 있기 때문에, 운영 체제는 필요하면 언제든지 해당 파일을 다시 읽어올 수 있음.
스왑 아웃과 비슷해 보이지만, 스왑 영역을 사용하는 건 아님!
왜냐면 굳이 스왑 영역을 쓰지 않고, 그냥 메모리에서 지웠다가 필요하면 매핑된 파일을 기반으로 다시 로딩하면 되기 때문임.
스왑 아웃, 스왑 인을 하는 과정보다 그냥 재로딩 하는 게 더 효율적임.
(단, 특정 상황에서는 스왑 영역으로 갈 수도 있음.)
가상 메모리로 사용되는 디스크 영역
사용되지 않는 페이지를 교체 알고리즘에 따라 스왑 영역으로 이동
그리고 필요할 때 다시 메모리로 로드(스왑 인)
물리 메모리보다 접근 속도 느리지만, 용량이 크고 비용이 적다
DMA
CPU 개입 없이 디스크와 메모리 사이에 데이터 입출력 하는 하드웨어 장치
CPU는 다양한 작업을 수행하는 범용 프로세서이지만,
DMA는 데이터 전송 작업에 특화된 장치
코로나로 참석은 못하고 팀원에게 전달해서 들음
1. 비전공자 이력서는 후킹 요소가 있어야 된다. 평범한 이력서 안 보게 된다.
2. 파일 제출은 hwp로 하지 마라.(PDF?)
3. 노션 이력서 제출은 권장하지 않는다는 뉘앙스
4. 여백도 잘 고려해라. 한 눈에 알아볼 수 있어야 함. 하단 여백이 너무 많이 남으면 이상하다.
5. 각 회사에서 원하는 내용으로 이력서를 써야 한다.
확실히 강의실에 있을 때와 기숙사에서 혼자 공부할 때 집중도가 다름. 강의실에 오면 시간 가는 줄 모르게 집중하게 됨.