@ 여기서는 Scheduling 관련해서만 설명하도록 해야 합니다.
// Policy와
// Mechanism을 분리 시켜야 합니다.
@ 이 때까지는 Policy에 대해서 얘기했습니다.
// 누구에게 CPU를 주고 얼마만큼 줄것인가를 보았습니다.
@ 그럼 지금부터는 Mechanism을 보겠습니다.
@ Scheduling Policy는 어떤 영향을 주게 될까요?
// 어떤 Process를 먼저 수행시키는가에 따라서
> Waiting 타임이 매우 차이가 많이 납니다.
@ Scheduling Objective가 존재합니다.
// Resource Utilization 극대화 해야 합니다.
> 어떤 Resource가 존재할 때
.. 전체 컴퓨터 uptime 중에 얼마만큼 시간동안 유의미한 수행을 했는가입니다.
> CPU, I/O 등을 확인해야 합니다.
>
// Overhead를 줄여야 합니다.
> OS가 스케쥴링을 하기 위해서는 의사결정을 해야 하며 이는 코드가 돈다는 의미가 됩니다.
// 이는 Process에 비례하거나
// 다른 것에 영향을 받을 수 있습니다.
> 이 때 코드가 가장 적게 도는 방향을 지향해야 합니다.
// 너무 빈번하게 Scheduler가 돌지 않게 해야합니다.
> 모드 체인지가 빈번하지 않아야 한다는 의미입니다.
// CPU time을 Fairness하게 나눠주는 것입니다.
> Application의 Fairness는 상황에 따라 다릅니다.
.. 우선순위 시스템의 경우의 상황과
.. 1/n 시스템을 적절히 잘 반영해야 합니다.
.. 그렇다고 우선순위를 너무 남발하면, 어떤 Task가 영원히 수행이 되지 않을 수도 있습니다.
// 테스크가 기다린 시간에 비례하여
> 우선순위를 높여주는
.. Aging이라는 방법을 추가하게 됩니다.
// 이렇게 발전해 왔습니다.
@ Matix들도 존재합니다.
// Waiting Time 최소화합니다.
// Response Time 최소화합니다.
> User Interactive한 시스템
// ThroughPut을 극대화하고
> 시간당 만들어내는 Process개수를 의미합니다.
.. 여기에 민감한 Application은 CPU Intensive 한 것들이 있습니다.
// ThroughOut
// 이러한 것들을 잘 Trade-off를 잘 맞추어야 합니다.
> 이것이 OS의 지상과제가 됩니다.
@ Android가 그래서 초반에는 Response Time이 매우 느렸습니다.
// Linux를 사용했기 때문에 그랬죠
@ IOS는 자체적인 OS를 맞추어 최적화가 잘 되었습니다.
