🔥딱 8일간! 인프런x토스x허먼밀러 역대급 혜택

블로그

ostep / 가상화 / CPU / 원리: 제한적 직접 실행 (한글판 9장, 영문판 6장)

들어가며이 책에서는 어떤 문제를 해결하는 개념을 다룰 때 다음의 2가지로 나누어 설명하고 있습니다.저수준 기법 (mechanism)어떻게 문제를 해결할 것인지예: 어떻게 CPU 가상화를 할 것인지 -> 제한적 직접 실행고수준 정책 (policy)문제를 해결해서 무엇을 할 것인지예: 가상화한 CPU자원을 어떤 프로세스에게 할당할 것인지 -> CPU 스케줄링CPU 가상화들어가며CPU라는 자원은 시분할로 가상화하는 것이 자연스럽다.CPU 가상화 기법의 필요조건들빨라야 한다.기법: 제한적 "직접 실행"사용자 프로세스는 가상의 명령어를 해석하는 것이 아니라, 하드웨어에서 지원하는 명령어를 직접 실행한다.예를 들어서 x86 CPU에서 돌아가는 OS의 경우 x86 기계어를 직접 실행한다.일부 명령어는 사용자 프로세스가 사용할 수 없어야 한다.예: 입출력장치에 직접 접근하는 명령어는 사용자 프로세스가 아닌 커널에서만 사용할 수 있다.기법: "제한적" 직접 실행하드웨어 지원 기능: mode bit, trap 및 return-from-trap 명령어 OS의 특정 기법을 구현하기 위해서는 하드웨어가 지원하는 기능과 운영체제 소프트웨어가 협력하는 경우가 많다.mode bitmode bit은 CPU에 존재하며 mode bit의 세팅 여부에 따라 커널 모드(kernel mode)와 사용자 모드(user mode)로 나뉜다.CPU는 사용자 모드인 경우 일부 명령어들의 실행만 지원한다.지원하지 않는 명령어를 실행할 경우 interrupt가 발생하여 OS가 문제의 프로세스를 kill할 수 있다.trap, return-from-trap 명령어위와 같이 사용자 프로세스는 일부 명령어를 직접 실행하지 못하고 OS를 통해 간접적으로 실행해야 한다. 이 과정에서 사용할 수 있는 명령어들이 trap 및 return-from-trap 명령어들이다.trap 명령어kernel mode로 전환하고, 해당 trap과 관련된 커널의 코드가 실행된다.이 때 trap 0xdeadbeef와 같이 trap 명령어에 임의의 주소값을 전달할 수 있다면 사용자 프로세스가 임의의 커널 코드를 실행시킬 수 있는 큰 문제가 일어난다.따라서 trap 명령어 실행 시 실행시킬 수 있는 handler가 몇 개로 정해져 있다. 이를 trap table이라 한다. trap 0x80과 같이 trap 명령어는 index를 전달하는 방식으로 동작한다.CPU에서 trap handler를 등록하는 방법을 별도로 제공해주며, 커널은 이를 사용하여 부팅 시 trap table을 초기화한다.x86 아키텍처에서는 trap 명령어를 int라고 부르지만, 교재와 강의에서는 trap 명령어와 인터럽트를 구분해서 설명하고 있다.필자 주: 공룡책에서 시스템 호출은 소프트웨어 인터럽트 중 하나로 처리된다고 말하는 것으로 볼 때, 여기서 ostep에서 구분하고자 하는 인터럽트는 하드웨어 인터럽트로 추정됩니다.return-from-trap 명령어user mode로 전환하고 trap 명령어를 호출한 곳으로 되돌아간다.⚠ 필자 주: 인터넷에서 잠깐 찾아보았을 때 trap이라는 단어가 다른 맥락에서도 사용됨을 확인했습니다. 조사한 바로는 trap 및 여러 단어들의 용례가 사용되는 의미가 하나로 합의되지는 않았다고 합니다. 하지만 여기서도 공룡책에서도 "trap instruction"라는 용어가 일관적으로 사용되는 것으로 보았을 때 OS 공부할 때 "trap 명령어"라는 말을 사용해도 무방해 보입니다.사용자 프로세스 하나가 실행 중일 때 제어권을 가져와서 다른 사용자 프로세스로 넘기는 과정이 필요하다.예전에 사용했던 기법: 협조(cooperative) 방식사용자 프로세스가 제어권을 양보할 때까지 OS가 기다린다.문제: 사용자 프로세스가 프로그래머의 실수든 고의든 오랫동안 제어권을 양보하지 않으면 OS는 제어권을 가져올 수 없다.현재 사용하는 기법: 비협조 방식하드웨어 지원 기능: timer interruptCPU에서 일정 갯수의 클럭 실행 후 발생시키는 인터럽트timer interrupt 발생 시 제어권이 interrupt handler로 넘어가 OS가 다시 제어권을 가져올 수 있다.문맥 전환 (context switch)문맥 전환 시 저장해야 하는 데이터: 레지스터, PC, SP출처강의: https://pages.cs.wisc.edu/~remzi/Classes/537/Fall2021/Discussion/videos.html책: https://pages.cs.wisc.edu/~remzi/OSTEP/Korean/

시스템 · 운영체제osostep

ostep / 가상화 / CPU / MLFQ (한글판 11장, 영문판 8장)

들어가며이번 장에서는 멀티 레벨 피드백 큐(MLFQ, Multi-Level Feedback Queue)에 대해서 다룹니다.이전 장에서 다룬 내용 중 이번 장에서 가장 중요한 내용 2가지를 꼽자면 다음과 같습니다.반환 시간을 최적화하기 위해서는 짧은 작업을 먼저 실행시켜야 한다. 평균적으로 대기하는 작업 수를 최소화해야 해서 그렇습니다.연관 개념: SJF, STCF 알고리즘응답 시간이 짧아지면 짧아질수록 반환 시간이 길어진다. 평균적으로 대기하는 작업 수가 늘어나서 그렇습니다.연관 개념: 라운드 로빈 알고리즘, 타임 슬라이스MLFQ 알고리즘은 이전 장에서 다루었던 가정 중 마지막 가정인 "작업의 시간이 사전에 알려져 있다"마저 없앤 현실적인 가정 하에 동작합니다. 현대 운영체제에서 적용하는 알고리즘의 뼈대가 됩니다.Ostep에서 이 장을 진행하는 구성은 다음과 같습니다.먼저 특정 시각에 MLFQ가 어떻게 동작하는지를 먼저 기술합니다. (Multi, Level, Queue)그리고 시간에 따라 피드백을 받으며 조정하는 부분을 기술합니다. (Feedback)개요MLFQ 알고리즘이 달성하고자 하는 목표는 다음과 같습니다.사용자가 실시간으로 기다리는 대화형 작업의 경우 응답 시간을 최소화이외의 작업의 경우 반환 시간을 최소화이를 어렵게 하는 난관은 다음과 같습니다. 사용자 작업의 소요 시간 및 특성을 사전에 알 수 없습니다.응답 시간을 최적화할 경우 반환 시간이 안 좋아지는 트레이드오프가 있습니다.이를 해결하기 위한 전략은 다음과 같습니다.작업이 지금까지 보여준 과거를 통해서 미래를 예측한다.기본적인 모델먼저 MLFQ가 특정 시각에 어떻게 동작하는지 살펴보겠습니다.먼저 MLFQ의 M, L, Q에 해당되는 부분입니다.Queue: 작업은 큐에서 대기합니다.Multi: 그런데 큐를 여러 개를 둡니다.Level: 그런데 그 여러 개의 큐들의 우선순위에 차등을 둡니다.우선 순위에 따른 동작은 다음과 같습니다. 규칙 1: 우선 순위가 높은 작업이 먼저 실행된다.규칙 2: 우선 순위가 같은 작업은 라운드 로빈 알고리즘으로 실행된다.이를 구현하기 위해서는 다음과 같습니다.우선 순위가 가장 높은 큐에 작업이 있으면, 라운드 로빈 알고리즘에 따라 다음 실행할 작업을 결정한다.우선 순위가 가장 높은 큐에 작업이 없으면, 다음 우선순위 큐로 넘어간다.우선 순위가 가장 낮은 큐까지 반복한다.시간에 따른 변화를 고려한 모델 (mk1)특정 시각으로 시간을 고정할 경우 작업마다 (과거에 실행된 것을 바탕으로) 우선 순위가 고정되어 있습니다. 하지만 특정 시각의 동작만 가지고는 초기에 정보가 없을 때 우선 순위를 어떻게 설정해야 하는지, 또 어떻게 변하는지에 대하는지 이해할 수 없습니다. 따라서 이 섹션에서는 시간에 따른 변화를 고려해보겠습니다. 일단 규칙부터 보여드리겠습니다.규칙 3: 모든 작업은 초기에는 가장 높은 우선순위로 실행된다.다시 말해 처음 생성된 작업은 우선순위가 가장 높은 큐에 대기시킵니다.규칙 4a: 주어진 타임 슬라이스를 모두 사용하면 우선순위를 한 단계 강등시킨다.즉, 우선 순위가 한 단계 낮은 큐에서 대기시킵니다.규칙 4b: 주어진 타임슬라이스를 모두 사용하지 않으면 우선순위를 유지시킨다.즉, 같은 큐에서 대기시킵니다.ostep에서 Q2 > Q1 > Q0인 3개의 큐를 둔 예시를 설명하고 있습니다. 책을 보시는 게 좋을 것 같아 여기서는 결론만 정리하겠습니다.실행 시간에 따른 분석긴 실행 시간을 가진 작업: Q2 -> Q1 -> Q0로 떨어져서 낮은 우선 순위로 실행짧은 실행시간을 가진 작업: Q2, Q1 등 높은 우선 순위에서 실행 후 완료짧은 실행 시간을 가진 작업을 더 높은 우선순위로 실행시켜 반환 시간을 최적화하는 것을 알 수 있습니다.입출력 작업: 주어진 타임 슬라이스가 끝나기 전에 입출력을 수행한다면 우선 순위 유지한다고 가정대화형 작업의 경우 타임 슬라이스가 종료되기 전에 입출력을 수행해 높은 우선 순위로 실행되어 응답 시간을 최적화할 수 있습니다.mk1의 문제점기아 상태(starvation)대화형 작업 여러 개가 존재한다면, 높은 우선순위의 큐만 실행하느라 낮은 우선순위 큐에 있는 CPU 위주 작업은 계속 실행되지 못하는 가능성이 있습니다.높은 우선순위를 유지하는 꼼수 존재CPU를 오래 사용하는 작업이더라도 타임 슬라이스가 끝나기 직전에 입출력을 수행한다면 높은 우선 순위를 유지할 수 있습니다.따라서 이 문제를 해결하기 위해서 타임 슬라이스 사용 여부의 boolean이 아닌, 타임 슬라이스의 얼마가 남아있는지를 저장해야 합니다.시간에 따른 작업의 특성 변화 고려 못함CPU 작업이 대화형 작업으로 변화할 수 있지만, mk1에서는 우선 순위가 내려간 작업은 다시 올라오지 않기 때문에 대화형 작업의 응답 시간이 길어질 가능성이 있습니다.시간에 따른 변화를 고려한 모델 (mk2)꼼수 문제를 해결하기 위해서 4번 규칙을 보완하겠습니다.규칙 4: 주어진 타임 슬라이스를 모두 사용하면 우선순위를 한 단계 강등시킨다. 단, CPU를 몇 번 양도하였는지와 상관없이 시간 할당량을 소진하는 것으로 강등 여부를 판단한다.즉, 남은 시간을 확인해서 0이라면 우선 순위가 한 단계 낮은 큐에서 대기시킵니다. 반면 0이 아니라면 같은 큐에서 대기시키되, 남은 시간을 저장하여 다음 실행 시에는 타임 슬라이스 시간이 아닌 남은 시간동안만 실행되도록 합니다.기아 상태 문제와 작업 특성 변화 문제를 해결하기 위해서 규칙을 하나 더 만들겠습니다.규칙 5: 일정 시간 S가 지나면 모든 작업을 최상위 큐로 이동시킨다. MLFQ의 조정과 다른 쟁점들MLFQ에는 정확하게 결정하기 위해서는 흑마법이 필요해 보이는 "부두 상수"들이 몇 가지 있습니다.큐의 개수큐 별 타임 슬라이스 길이우선 순위가 높으면 대개 타임 슬라이스가 짧습니다. 대화형 작업이 많기 때문입니다. (<10ms)우선 순위가 낮으면 응답 시간보다는 반환 시간을 최적화하기 위해서 타임 슬라이스가 깁니다.ostep에서 다룬 것과 같이 정확한 규칙이 아닌, 수학 공식을 사용하여 우선순위를 조정하기도 합니다.또한 스케줄러는 다른 기능을 제공하기도 합니다. 사용자 작업에 대해서 우선순위를 정하게 해주는 nice와 같은 기능이 그 예입니다. 정리Ostep에서 다룬 MLFQ 알고리즘의 경우 다음 5가지 규칙으로 정리할 수 있습니다.규칙 1: 우선 순위가 높은 작업이 먼저 실행된다.규칙 2: 우선 순위가 같은 작업은 라운드 로빈 알고리즘으로 실행된다.규칙 3: 모든 작업은 초기에는 가장 높은 우선순위로 실행된다.규칙 4: 주어진 타임 슬라이스를 모두 사용하면 우선순위를 한 단계 강등시킨다. 단, CPU를 몇 번 양도하였는지와 상관없이 시간 할당량을 소진하는 것으로 강등 여부를 판단한다.규칙 5: 일정 시간 S가 지나면 모든 작업을 최상위 큐로 이동시킨다.그 결과로 MLFQ는 반환 시간과 응답 시간을 모두 최적화합니다. 짧게 실행되는 작업은 SJF/STCF처럼 처리해 전반적인 성능을 개선시키고, 오래 실행되는 CPU 작업의 경우 공정하게 실행되도록 기아 상태를 방지하고 조금이라도 진행되게 합니다. 이런 이유로 많은 운영체제에서 MLFQ를 기본 스케줄러로 사용하고 있습니다.출처강의: https://pages.cs.wisc.edu/~remzi/Classes/537/Fall2021/Discussion/videos.html책: https://pages.cs.wisc.edu/~remzi/OSTEP/Korean/

시스템 · 운영체제ostep

ostep / 가상화 / CPU / 스케줄링 정책 (한글판 10장, 영문판 7장)

들어가며ostep에서는 스케줄링 정책에 대해서 설명할 때 비현실적인 가정 하에 만든 단순화한 모델에서 시작해 가정을 하나씩 없애가면서 점점 복잡한 모델을 만들면서 최종적으로 현실에서 사용하는 모델에 다다릅니다.이 장에서는 작업의 실행 시간을 사전에 알 수 있는 경우까지만 다룹니다.책에서와 섹션 구성에 아주 살짝의 차이를 두었습니다.책에서는 알고리즘별로 섹션을 구성하여, 알고리즘을 설명하고, 가정을 완화한 다음에 생기는 문제를 같이 제시했습니다.저는 사용한 가정에 따라 섹션을 구성하여, 각 섹션별로 이전 섹션에서 가정을 완화한 모델을 제시하고, 이전 섹션에서 최적의 알고리즘을 적용했을 때 발생하는 문제를 제시하고 이를 새로운 모델로 해결하는 방향으로 풀어갔습니다.워크로드에 대한 가정모든 작업은 같은 시간동안 실행됩니다.모든 작업은 동시에 도착합니다.각 작업은 시작되면 완료될 때까지 실행됩니다.모든 작업은 CPU만 사용합니다.각 작업의 실행 시간은 사전에 알려져 있습니다.스케줄링 알고리즘 한 눈에 살펴보기비선점형 스케줄링가장 단순한 모델모든 가정을 고려한 가장 단순한 모델에서 출발해보겠습니다.모델모든 작업이 같은 시간동안 실행되고,동시에 도착하고,시작하면 완료될 때까지 실행되고,CPU만 사용하고,실행 시간은 사전에 알려져 있습니다.평가 기준: 반환 시간이 때 스케줄링 알고리즘은 무엇을 최적화해야 할까요? 각 작업을 완료하는데 소요된 시간을 최적화할 수 있겠습니다. 이를 반환 시간으로 정의합니다. 계산할 때에는 주어진 정보를 활용하여 $(완료\ 시간) - (도착\ 시간)$으로 계산할 수 있겠습니다.알고리즘: FIFO모든 작업들이 시간적인 측면에서는 동일하기 때문에 어떤 순서로 실행해도 평균 반환 시간은 동일합니다.가장 심플하게 구현하자면 작업들이 나열된 순서대로 실행하는 알고리즘을 생각할 수 있겠습니다. 이 알고리즘을 FIFO (선입선출)라고 부릅니다.가정 완화: 작업들의 실행 시간이 항상 같지는 않다면?이전 모델에서 "모든 작업이 같은 시간동안 실행된다"라는 가정을 제거해보겠습니다.모델모든 작업이 동시에 도착하고,시작하면 완료될 때까지 실행되고,CPU만 사용하고,실행 시간은 사전에 알려져 있습니다.평가 기준: 반환 시간FIFO의 문제: Convoy Effect선입선출 알고리즘에서 길이가 각각 10, 10, 100인 작업이 다른 순서로 들어온 경우를 비교해보겠습니다.순서대로 시간이 10, 10, 100인 작업이 들어온 경우 반환시간이 각각 10, 20, 120이며, 평균 반환시간은 $\frac{10+20+120}{3} = 50$입니다.순서대로 시간이 100, 10, 10인 작업이 들어온 경우 반환시간이 각각 100, 110, 120이며, 평균 반환시간은 $\frac{100+110+120}{3} = 110$입니다.각각의 작업의 소요 시간은 같은데 평균 반환시간이 이렇게 차이가 나는 이유는 앞에 시간이 오래 걸리는 작업이 있어서 뒤의 짧게 끝나는 작업들이 모두 긴 시간을 기다리기 때문입니다.이 효과를 Convoy Effect라고 합니다.해결 방법: SJFConvoy Effect를 최소화하려면 작업 시간이 최소인 작업부터 순서대로 실행해야 합니다.이렇게 대기 중인 작업 중 소요 시간이 최소인 작업부터 실행하는 알고리즘을 최단 작업 우선(Shortest Job First, SJF)라고 합니다.SJF 알고리즘은 현재 가정 하에서 평균 반환 시간을 최소화함이 수학적으로 증명되어 있습니다.여담: 수학적인 증명 스케치가정에 의해 모든 작업이 동시에 도착하기 때문에 모든 작업 목록이 도착 시점에 정해짐을 알 수 있습니다.작업 목록의 개수가 정해져 있을 때 평균 반환 시간을 최적화하는 것과 총 반환 시간을 최적화하는 것은 같습니다. $(평균\ 반환\ 시간) = \frac{(총\ 반환\ 시간)} {(작업\ 개수)}$이기 때문입니다.총 반환 시간총 반환시간은 각 작업의 반환시간, 즉 각 작업이 완료되기까지 기다려야 하는 시간을 모두 합하여 구할 수 있습니다. 다른 방법으로는 각 작업이 실행되는 동안 작업들이 실행 및 대기중인 시간을 모두 합할 수도 있습니다. 그림으로 나타내면 다음과 같습니다.먼저 실행하면 실행할수록 많은 작업들이 대기 중이므로, 많은 작업들이 짧은 시간동안만 대기하도록 짧은 작업의 순서대로 실행시키는 알고리즘이 총 반환시간을 최소화합니다.엄밀하게는 재배열 부등식을 통해 증명할 수 있습니다. 가정 완화: 작업들이 모두 같은 시간에 도착하지는 않는다면?책에서는 별도로 다루지 않았으므로 짧게 넘어가겠습니다. 이 경우에도 각 작업이 끝날 때마다 대기 중인 작업 중 가장 짧은 작업을 실행시키는 SJF 알고리즘이 최적의 알고리즘입니다.아까전의 예시에서 시간이 각각 10, 10, 100인 작업들이 간발의 차로 100, 10, 10의 순서대로 도착한다고 가정해보겠습니다. 그렇다면 SJF 알고리즘을 적용하여도 최적의 평균 대기 시간은 $\frac{100 + 110 + 120}{3} = 110$이 되겠습니다.선점형 스케줄링들어가며지금까지는 "작업이 시작하면 완료될 때까지 계속 실행된다"는 가정 하의 스케줄링 알고리즘에 대해서 살펴보았습니다. 이는 예전에 많이 사용했던 일괄 처리 시스템에서 유효하게 사용되었던 가정입니다. 이런 가정 하의 스케줄러를 비선점(non-preemptive) 스케줄러라고 합니다.반면 현대 운영체제에서는 OS가 한 프로세스의 실행을 중단시키고 다른 프로세스에게 실행권을 넘길 수 있습니다. 구체적으로 말하면 스케줄러는 앞 장에서 다루었던 문맥 교환을 수행할 수 있습니다. 이렇게 한 작업을 중단시키고 다른 작업을 처리하는 스케줄러를 선점 스케줄러라고 하며, 현대 OS에서 사용하는 거의 모든 스케줄러는 선점 스케줄러입니다.가정 완화: 작업이 완료되기까지 기다리지 않아도 된다면?모델모든 작업은 CPU만 사용하고,실행 시간은 사전에 알려져 있습니다.평가 기준: 반환 시간 SJF의 문제: Convoy Effect아까전에 보았던 간발의 차로 100, 10, 10의 순서대로 작업이 도착하는 상황을 생각해보겠습니다.앞의 상황에서는 작업이 끝날 때까지 기다려야 한다는 가정이 있었습니다.따라서 SJF 알고리즘을 적용하여도, 나중에 도착한 짧은 작업이 이미 시작한 긴 작업을 중단할 수 없었기 때문에 기다려야 했습니다. 다시 말해, 앞에 살펴보았던 Convoy Effect가 다시 발생했음을 확인할 수 있습니다.해결: STCF작업이 도착하는 족족 현재 실행 중인 작업을 포함해서 SJF 알고리즘을 적용한다고 생각하면, 현재 시점에서 가장 잔여 시간이 적은 작업을 먼저 실행해야 한다는 사실을 알 수 있습니다. 이를 STCF (Shortest Time-to-Completion First)라고 부릅니다. 새로운 평가 기준: 응답 시간일괄 처리 시스템에서는 작업의 반환 시간을 최적화하는 것과 작업이 처음 실행되는 시간을 최적화하는 것이 좋은 평가 기준이었습니다.하지만 시분할 컴퓨터가 등장하면서 사용자가 상호작용을 하면서 응답 시간이라는 새로운 평가 기준이 중요해지기 시작했습니다.ostep에서는 응답 시간을 작업이 도착하기부터 처음 스케줄될 때까지의 시간으로 정의합니다.수식으로는 다음과 같이 정의합니다: $(응답\ 시간) = (첫\ 실행\ 시간) - (도착\ 시간)$응답 시간을 최적화하는 알고리즘모델모든 작업은 CPU만 사용하고,실행 시간은 사전에 알려져 있습니다.평가 기준: 응답 시간문제반환 시간을 최적화하는 알고리즘의 경우 응답 시간이 길어지는 경우가 있습니다. 예를 들어 10초짜리 작업이 10개가 대기하고 있다면 대기 중인 11초짜리 작업은 응답시간이 최소 100초가 되겠습니다.알고리즘: Round RobinRound Robin 알고리즘은 정해진 타임 슬라이스(time slice) 혹은 스케줄링 퀀텀(scheduling quantum)동안 현재 작업을 실행 한 후 대기 중인 다음 작업으로 넘어갑니다.타임 슬라이스의 길이응답 시간 측면에서는 짧은 것이 좋습니다.문맥 교환 비용의 상쇄(amortization) 측면에서는 긴 것이 좋습니다.이 둘을 고려해서 적절한 길이로 설정해야 합니다.트레이드오프: 공정한 정책의 경우 반환 시간이 안 좋습니다.동일한 작업을 가지고 공정한 정책과 불공정한 정책을 비교해 보겠습니다.두 정책 모두 총 CPU 사용 시간은 동일합니다. (문맥 교환 비용은 상쇄되었다고 가정하겠습니다.)공정한 정책의 경우 CPU의 시간을 골고루 나누어주기 위해서 실행 중인 작업을 중단시키고 대기시키는 과정이 있습니다. 이로 인해 CPU 사용 중에 더 많은 작업들이 대기 중이게 됩니다.총 실행 시간이 같을 때, 대기 중인 작업이 더 많을 때 총 반환 시간이 커짐을 알 수 있습니다.표로 만들어서 각 시간대별로 비교해보시면 비교가 쉽습니다. (아래 표에서는 세로줄끼리 비교)시간이 10, 10, 100인 작업이 도착했을 때 첫 번째 표는 STCF, 두 번째 표는 time slice를 5로 놓은 RR입니다.입출력 연산의 고려모델모든 작업은 CPU와 입출력을 모두 사용하고,실행 시간은 사전에 알려져 있습니다.알고리즘한 개의 작업이 CPU를 사용하다가 입출력 작업으로 넘어갈 경우, 입출력을 대기하고 있는 CPU 자원을 다른 작업에게 할당한다면 시스템을 더 잘 활용할 수 있습니다.이를 구현하기 위해서 각 입출력 작업 사이의 CPU 작업들(CPU 버스트)을 별개의 작업으로 간주하면 기존의 정책을 그대로 적용하면서 입출력 대기중일 때 다른 작업을 수행할 수 있게 됩니다.나가며이렇게 실행 시간이 사전에 알려져 있는 경우에 여러 가지 알고리즘을 학습하고 비교하였습니다. 하지만 현실에서는 작업의 실행 시간이 얼마인지 사전에 알고 있다는 가정은 비현실적입니다. 따라서 다음 장에서는 사전 지식 없이 반환 시간과 응답 시간을 모두 고려하는 알고리즘에 대해서 다루게 됩니다.출처강의: https://pages.cs.wisc.edu/~remzi/Classes/537/Fall2021/Discussion/videos.html책: https://pages.cs.wisc.edu/~remzi/OSTEP/Korean/

시스템 · 운영체제ostep

채널톡 아이콘