@ FIFO의 문제가 Round Robin Scheduling Algorithm 으로 다 해결될까요?
// 그렇지 않습니다.
// 일반적으로는 Robin이 더 잘합니다.
// 하지만 가끔은 FIFO가 더 좋은 성능을 보이기도 합니다.
> 각 10개의 Process Response Time(burst)가 10ms이라고 생각해봅니다.
.. Robin에서 전부 수행시키면 평균 수행시간이 약 1000이 됩니다.
.. 점차적 실행... 1000-Alpha
.. FIFO에서는 평균 수행시간이 500이 됩니다.
.. 100 + 200 + 300 + ... + 1000
// 그렇기에 항상 FIFO가 나쁘다고 할 수는 없습니다.
@ 어떤 Workload에 대해서는 각각이 좋은 상황이 있습니다.
// 여기에서 WorkRoad의 패턴을 볼 수 있습니다.
> 언제 좋고, 언제 나쁜지에 대해서
.. CPU Burst를 보며 알 수 있습니다.
// Workload에 따라서 Algorithm을 변경할 수 있어야 합니다.
> Dinamic하게
.. 사람들은 이런 방식을 생각하기 시작합니다.
@ 그렇게 나온 것이 Adaptive Scheduling
// Workload에 따라 Time Slice의 크기를 바꿔줍니다.
> I/O Bound Process(Proc1)
.. 대부분의 시간을 Waiting에 사용합니다.
.. I/O Response Time을 줄이는 것이 중요합니다.
> CPU Bound Process(Proc2)
.. 대부분의 시간의 CPU에 씁니다.
.. CPU Utilization이 중요한 척도이며
.. Throuput 이 중요해집니다. (주어진 CPU시간 동안 얼마나 많이 수행했는가)
@ 그렇다면 각각의 방식에서 어떤 Scheduling 방식을 사용하는 것이 좋을까요?
// i) FIFO, ii) Round Robin
.. i) CPU Utilization 100 %
.. i) I/O Utilization 10/101
.. ii) CPU Utilization 100 %
.. ii) I/O Utilization 10/11
// 기본적으로 둘 다 약점을 가지게 된다는 것을 알 수 있습니다
> 위의 예시는 FIFO가 좋았지만
> 전체적으로는 Time quntum이 작은 편이 좋습니다.
@ 그렇다면 어떻게 극복하면 좋을까요?
// 기본적인 틀로는 짧은 Quentum Size로 시작하고
> 위에서 나타난 문제를 해결합니다.
.. Adaptive Scheduling을 하는 것입니다.
@ Adaptive Scheduling에서는
// CPU Bound Process에세는 긴 Time Quentum을 줍니다.
// I/O Bound Process에세는 짧은 Time Quentum을 줍니다.
@ 이렇게 하기 위해서는 OS가 CPU Bound인지 I/O Bound인지를 알아야 합니다.
// 이를 하기 위해서는, 초기 Time quntum을 주고
> 빠르게 결과를 내면 I/O Bound
> Time Quentum을 다쓰고도 남게 되면 CPU Bound임을 알 수 있습니다.
// 이를 효과적으로 하기 위해서
> Multi Level Fidback Queue
.. 새로운 Process가 생성되고
.. 제일 처음 Queue로 들어갑니다. (우선순위 높음, Time Quentum 짧음)
.. 수행을 시켜서 Time Quentum을 얼마나 쓰는지 확인하고
.. 이에 따라 위치하는 Queue를 바꿔갑니다
.. 그리고 Time Quentum은 Exponential하게 커갑니다 (1, 2, 4, 8, ...), 우선순위는 낮아집니다.
> 이렇게 Time Quentum을 효과적으로 Process마다 다르게 적용시킬 수 있습니다.
> 이를 적용한 상황을 보여드리겠습니다.
@ OS의 개념 중 가장 중요한 개념 중 하나는
// Process이며
// 가장 중요한 매커니즘은
> Multi Level Fidback Queue입니다.
.. 정말 훌룡한 Scheduling 방식입니다.
// 그리고 이 매커니즘이 왜 나오게 되었는지 잘 알고 있을 필요가 있습니다.
@ 그러면 실제로는 이 스케쥴러를 많이 사용할까요?
// Linux OS는 Desktop OS로 시작해서
> Server OS로 확장되고
.. 임베디드 OS로 확장됩니다.
// 지금은 스마트폰과, 자동차 등에서도 자주 사용됩니다.
// 요새는 거의 듀얼 및 쿼드코어를 사용하고 있으며
> 더 복잡해지고 있습니다.
.. Scheduler는 실제로는 더 복잡하게 이루어지고 있습니다.
