[OSTEP] 스터디 2주차 - 가상화의 세계 - 숙제

소개

이 프로그램 process-run.py를 통해 프로그램이 실행되고 CPU를 사용하거나(예: 명령어 추가 수행) I/O를 수행할 때(예: 디스크에 요청을 보내고 완료될 때까지 기다림) 프로세스 상태가 어떻게 변하는지 볼 수 있다. 자세한 내용은 README를 참조하라.

---

질문

Q1. 다음 플래그와 함께 process-run.py를 실행하세요: -l 5:100,5:100. CPU 활용률(예: CPU가 사용 중인 시간의 백분율)은 어떻게 되어야 할까요? 왜 그렇게 알 수 있나요? -c와 -p 플래그를 사용해 여러분의 생각이 맞는지 확인해 보세요.

A : 5ms 실행하고 100ms 기다리는 것을 2번 하기 때문에 10% 정도로 생각했다. (5:100)의 의미를 잘 몰랐다.

하지만 100%가 나왔다. 보니 I/O 대기가 없다. 그러니 100 가 나오는 것이다.

Q2. 이제 다음 플래그로 실행해 보세요: ./process-run.py -l 4:100,1:0. 이 플래그는 4개의 명령어(모두 CPU 사용)를 가진 하나의 프로세스와 I/O를 실행하고 완료될 때까지 기다리는 하나의 프로세스를 지정합니다. 두 프로세스를 모두 완료하는 데 얼마나 걸리나요? -c와 -p를 사용해 여러분의 생각이 맞는지 확인해 보세요.

A : 4:100 은 4개의 명령어를 100%의 확률?로 CPU 작업을 하는 프로세스와 1개의 명령어를 I/O 작업만 하는 프로세스로 생성한다는 것 같다. 그럼 time? 5가 나올 것 같다.

11이 나왔다... 왜 그럴까? self.io_finish_times[self.curr_proc].append(clock_tick + self.io_length + 1) 이 코드 때문에 4 + 1 + 1 해서 6만큼 추가로 걸린 것 같다.

Q3. 프로세스의 순서를 바꿔 보세요: -l 1:0,4:100. 이제 어떻게 되나요? 순서를 바꾸는 것이 중요한가요? 왜 그런가요? (항상 그렇듯이 -c와 -p를 사용해 여러분의 생각이 맞는지 확인해 보세요)

7이 나올 것 같다. PID 0의 I/O 요청은 tick 1에 실행되었고, I/O 길이는 기본 5 이기 때문에 I/O 실행은 7초에 다시 진행 그리고 그 사이 CPU 작업이 모두 끝나서 7에 끝난다. Q2에서는 CPU가 4 tick을 먼저 사용하고 I/O 대기가 5 tick부터 시작했다. 그 상태에서 5 + 1 tick을 추가로 기다리니 11 tick에서 종료되었던 것이다.

Q4. 이제 다른 플래그들을 살펴보겠습니다. 중요한 플래그 중 하나는 -S인데, 이는 프로세스가 I/O를 실행할 때 시스템이 어떻게 반응하는지 결정합니다. 플래그를 SWITCH_ON_END로 설정하면 한 프로세스가 I/O를 수행하는 동안 시스템은 다른 프로세스로 전환하지 않고 해당 프로세스가 완전히 끝날 때까지 기다립니다. 다음 두 프로세스를 실행할 때 어떤 일이 일어나나요(-l 1:0,4:100 -c -S SWITCH_ON_END), 하나는 I/O를 수행하고 다른 하나는 CPU 작업을 수행합니다?

프로세스 전환이 없다고 하면 처음 I/O 작업에서 1 + 5 + 1초 기다릴 것이고 그럼 7 tick에 끝난다. 이후 CPU 작업 4 tick을 하면 11 tick에 끝날 것 같다.

Q5. 이제 같은 프로세스를 실행하되, 한 프로세스가 I/O를 기다리는(WAITING) 동안 다른 프로세스로 전환되도록 switching 동작을 설정해 봅시다(-l 1:0,4:100 -c -S SWITCH_ON_IO). 이제 어떤 일이 일어나나요? -c와 -p를 사용해 여러분의 생각이 맞는지 확인해 보세요.

Q3처럼 7 tick에 끝날 것이다.

Q6. 또 다른 중요한 동작은 I/O가 완료될 때 수행할 작업입니다. -I IO_RUN_LATER를 사용하면 I/O가 완료될 때 그것을 실행한 프로세스가 반드시 즉시 실행되는 것은 아닙니다. 오히려 그 시점에 실행 중이던 프로세스가 계속 실행됩니다. 이러한 프로세스 조합을 실행하면 어떤 일이 일어나나요? (./process-run.py -l 3:0,5:100,5:100,5:100 -S SWITCH_ON_IO -I IO_RUN_LATER -c -p) 시스템 자원이 효율적으로 활용되고 있나요?

실행 중이던 프로세스가 계속 실행된다? 그럼 I/O 작업 중에 CPU 작업이 일어나지 않을 것 같고 각 작업을 별도로 실행해서 31 tick에 끝난다?

Q7. 이제 같은 프로세스를 실행하되, -I IO_RUN_IMMEDIATE를 설정해 I/O를 실행한 프로세스를 즉시 실행하도록 해 봅시다. 이 동작은 어떻게 다른가요? 방금 I/O를 완료한 프로세스를 다시 실행하는 것이 왜 좋은 생각일 수 있을까요?

7 tick 작업을 하는 것이 3번 실행돼서 21 tick이 나올 것 같다. 

IO_RUN_LATER일 경우: Tick 7에 I/O 완료돼도 바로 실행 안 될 수 있음 다른 프로세스가 READY 상태면 걔가 먼저 실행됨
IO_RUN_IMMEDIATE일 경우: I/O 끝난 순간 바로 그 프로세스를 실행시킴 불필요한 컨텍스트 스위칭 줄이고, 응답 시간 짧아짐

Q8. 이제 무작위로 생성된 프로세스로 실행해 봅시다: -s 1 -l 3:50,3:50 또는 -s 2 -l 3:50,3:50 또는 -s 3 -l 3:50,3:50. 추적 결과가 어떻게 될지 예측해 보세요. -I IO_RUN_IMMEDIATE 플래그와 -I IO_RUN_LATER 플래그를 사용할 때 어떤 일이 일어나나요? -S SWITCH_ON_IO와 -S SWITCH_ON_END를 사용할 때 어떤 일이 일어나나요?  

Seed	-S	-I	Total Time	CPU Busy	CPU %	IO Busy	IO %
1	IO	IMMEDIATE	15	8	53.33%	10	66.67%
1	END	IMMEDIATE	18	8	44.44%	10	55.56%
1	END	LATER	18	8	44.44%	10	55.56%
1	IO	LATER	15	8	53.33%	10	66.67%
2	IO	IMMEDIATE	16	10	62.50%	14	87.50%
2	END	IMMEDIATE	30	10	33.33%	20	66.67%
2	END	LATER	30	10	33.33%	20	66.67%
2	IO	LATER	16	10	62.50%	14	87.50%
3	IO	IMMEDIATE	17	9	52.94%	11	64.71%
3	END	IMMEDIATE	24	9	37.50%	15	62.50%
3	END	LATER	24	9	37.50%	15	62.50%
3	IO	LATER	18	9	50.00%	11	61.11%

SWITCH_ON_IO vs SWITCH_ON_END

• SWITCH_ON_IO가 항상 Total Time을 단축시킴
  • I/O 요청 즉시 다른 프로세스로 전환하여 CPU 낭비가 없음
• SWITCH_ON_END는 프로세스가 끝날 때까지 CPU를 잡고 있어서 CPU Idle Time 증가

IO_RUN_IMMEDIATE vs IO_RUN_LATER

• IO_RUN_IMMEDIATE는 I/O 완료 즉시 실행하여 응답성 향상
  • 특히 I/O 뒤에 짧은 작업(io_done)이 이어질 경우 매우 유리
• IO_RUN_LATER는 효율 낮음, I/O 완료 후 대기

시드 값(-s)이 주는 영향

• 명령 순서가 다르기 때문에:
  • I/O가 겹치면 둘 다 BLOCKED → 전체 시간 증가
  • I/O가 분산되면 효율 증가

설정	효과
SWITCH_ON_IO	CPU 낭비 최소화, Total Time 감소
IO_RUN_IMMEDIATE	응답 시간 향상, 효율적인 처리
SWITCH_ON_END	CPU 독점 시간 증가, 비효율
IO_RUN_LATER	I/O 후 실행 지연, 시스템 idle 증가
-s 변경	명령 순서 달라짐 → 결과 변화 유발