18장~24장_p271

[SeungBu]

스터디 자료 : Operating System Three Easy Pieces , xv6 Operating System
시간 : 01/10 ( PM 4:00 ~ PM 6:00 )
장소 : 미디어센터 508 호

1. 스터디및 발표자료 작성

• 발표자는 18장 ~ 24장 전체적인 그림 및 구조 설명

2. 현재 스터디 질문 제출

• 발표자 이외 인원은 01월 09 일까지 18장 ~ 24장 에 대하여 개인당 질문 3개를 만들어 issue 에 comment 로 제출

• issue에 질문 comment 작성

[SeungBu]

• p237 페이지들을 클러스터로 묶어서 한 번에 스왑 파티션에 저장한다는데 페이지들을 하나로 묶는 기준이 있을까용?

• 페이지디렉토리 갯수 구하는 방법이 궁금합니당!

• watermark에서 쓰레드가 페이지들을 제거하는데 백그라운드로 페이지 제거하는 작업보다
  메모리에 요청하는 양이 더 많아지는 경우에는 어떻게 수행하나용?

[kwanghee0124]

• Q1. 스왑영역도 결국에는 Disk에서 가져오는건데 그냥 Disk에서 찾는거와 스왑영역에서 가져오는 것의 차이는 뭔가요? 속도 측면에서 더 빠른가요?

--> 스왑 영역은 예약된 고속의 기억장치로써, p232에 스왑 공간에 대해 설명이 나와있는 것처럼 운영체제는 스왑 공간에 있는 모든 페이지들의 디스크 주소를 기억하고 있습니다. 따라서 일반 Disk에 가서 데이터를 찾아 가져오는 것보다, 필요할 때 스왑영역에서 바로 가져오는 부분에서 속도가 차이가 납니다.
제 생각에서 결론은, 필요한 데이터가 디스크의 어디에 쓰여있는지 찾는 과정이 생략된 속도 차이가 날 것입니다.

• Q2. 지금 현재 시스템에서는 멀티 레벨 페이지 테이블의 메모리 반복 접근 오버헤드보다 페이지 크기를 손해보는 것이 낫지 않나요? 지금 4레벨을 사용하고 있는데 차라리 3레벨 같이 한단계 내리는것이 메모리 접근을 줄임으로써 더 속도 측면에서는 좋지 않을까요?

--> 말씀하신게 더 속도 측면에서 좋습니다. 실제로 Huge Page가 그렇고요. 책 읽다가 어딘가에서 이 단원을 다룰 때 Huge Page는 우선 제외하고 일정크기의 Page일 때 관련해서 개선 관련 기법들을 소개된 것으로 압니다.