목차
- CPU 스케줄링 (선점/비선점 - preemptive/nonpreemptive, Dispatcher)
- 스케줄링 알고리즘 (FCFS, Round-Robin, SJF ...etc)
- 스레드 스케줄링 (멀티 스레드 멀티 코어, Load balancing, 캐시 선호도)
- 실시간 CPU 스케줄링 (Event latency, Rate monotonic, EDF)
- 실제 OS 사례
CPU Scheduling
컨셉 : "대부분의 작업은 CPU 사용이 짧다. → CPU가 작업 사이 쉬는 시간(메모리 로드/스토어)에 다른 작업을 시켜 쉬지 못하게 한다"를 통해 CPU 활용을 끌어 올리는것이 메인 컨셉입니다. 이유는 CPU, I/O, Memory에 작업 속도, 시간이 다른 점에서 각 작업들을 효율적으로 배분하는 생각입니다.
CPU Scheduler
CPU Scheduler는 실행 가능한(Ready) 메모리 내의 프로세스가 모여있는 Ready Queue에서 우선순위에 따라 하나를 선택해서 CPU코어에 전달합니다.
선점 / 비선점 스케줄링 (Preemptive / Nonpreemptive)
CPU 스케줄링은 다음 4가지 상황이 있습니다.
1. Running → Waiting (I/O 발생)
2. Waiting → Ready( I/O 완료)
3. Running → Ready (인터럽트 발생)
4. AnyState → Terminates (프로세스 종료)
선점, 비선점은 스케줄링에서 위 상황에 대해 어떤 선택을 하는지에 대한 이야기입니다.
비선점 스케줄링(Nonpreemptive) : CPU에 한 프로세스가할당되면 종료, 대기 상태로 바뀌는게 아닌 이상 CPU는 해당프로세스를 내려놓지 않습니다. 위 상황에서는 1번과 4번 상황이 아닌 이상 CPU가 현재 작업을 그만두지 않는 상태입니다. 즉 양보를 하지 않는 스케줄링입니다.
선점 스케줄링(Preemptive) : CPU는 한정된 시간 동안만 할당되는, 양보하는 스케줄링입니다. 일정 시간이 지났거나, 인터럽트나 시스템 호출로 더 높은 우선순위에 작업이 발생했거나 하는 경우 양보합니다.
이때 여러 작업이 데이터를 공유하는 경우 *race condition이 발생 가능합니다. → 해당 문제를 스핀락, mutex lock, monitor 등 동기화 기법을 이용해 회피합니다.
* race condition
경쟁 상태(race condition)
전산학에서 경쟁 상태(race condition)란 공유 자원에 대해 여러 개의 프로세스가 동시에 접근을 시도할 때 접근의 타이밍이나 순서 등이 결과값에 영향을 줄 수 있는 상태를 말한다. 동시에 접근하는 경우 자료의 일관성을 해치는 결과가 나타날 수 있습니다. (위키백과 - 경쟁 상태)
(예시)
만약 서로 다른 작업에 공유되는 자원인 counter = 5가 있을 때, 1번 작업에서는 counter++를 진행하고 2번 작업에서 counter --를 진행하면 이는 작업 순서에 따라 counter는 4, 5, 6의 값이 가능합니다.
4인 경우 : 1번 작업이 counter++을 위해 counter의 값을 로드하고, 그 즉시 2번 작업이 counter를 로드하여 1번 작업이 끝났을 때 2번 작업은 counter가 5인 시점을 로드하여 counter--를 진행해 4인 것을 확인하고 다시 저장해서 counter는 4값이 됩니다.
이와 마찬가지로 타이밍에 따라 4~6을 가질 수 있는 상태가 경쟁 상태입니다.
Dispatcher
디스패처(Dispatcher)는 CPU스케줄러가 선택한 작업을 CPU에게 전달하는 모듈로, 스케줄러 내에서 작업 실행 순서를 제어하는 역할입니다.(CPU 제어권을 전달) 아래와 같은 작업을 합니다.
- Context Switching : 한 프로세스에서 다른 프로세스로 옮겨가는 작업
- Switching to User mode : 사용자 모드로 전환하는 작업
- 프로그램을 재시작하기 위해 사용자 프로그램의 특정 위치로 점프하는 작업
Dispatch latency (디스패치 지연)이란 디스패처가 하나에 프로세스에서 다른 프로세스를 수행 시작을 하는데 소요되는 시간으로 아래 그림과 같은 과정이 일어납니다.
스케줄링
스케줄링 기준
다양한 CPU 스케줄링 알고리즘은 다음과 같은 기준을 토대로 선택됩니다.
- CPU 이용률(Utilization) : CPU를 최대한 효율적이고 바쁘게 유지합니다. 현실적으로는 리눅스에서는 CPU 사용량은 40%~90% 사이여야 합니다.
- 처리량(Throughput) : 단위 시간당 완료된 프로세스의 개수
- 반환 시간(Turnaround time) : 프로세스가 시작해서 끝날 때 까지 걸리는 시간
- 대기 시간(Waiting Time) : 스케줄러가 CPU 작업 시간이나 I/O 작업 시간을 줄일 수 없기에, 대기시간은 프로세스가 ready queue에 머무는 시간으로 정의
- 응답 시간(Response Time) : 하나의 Request를 전달한 후 첫번째 Response가 나올 때까지의 시간
* 반환시간이 같아도 응답시간이 짧으면 결과를 미리 볼 수 있는 효과가 있습니다.
* Interactive System에서 응답시간의 평균을 줄이는 것보다 편차를 줄이는 것이 일반적으로 더 중요합니다. → 사용자의 체감 편차, align필요
스케줄링 알고리즘
● FCFS (First Come First Served. 선입 선 처리) - 비선점(nonpreemptive)
FCFS 알고리즘은 가장 간단한 CPU 알고리즘으로, CPU를 먼저 요청한 프로세스가 CPU를 먼저 받는 방식입니다.
비선점 방식이기에 CPU는 프로세스가 종료되거나 대기상태로 변경되지 않는 이상 프로세스를 놓지 않습니다. 이 때문에 긴 시간을 잡아먹는 프로세스가 들어오면 나머지 프로세스들이 오랫동안 Ready 큐에 대기중인 상태가 발생합니다.
이렇게 긴 CPU-bound job 때문에 짧은 job이 계속적으로 CPU를 기다리는 현상을 Convoy effect라고 합니다. 앞에 차가 너무 느려서 뒤에 따라가는 차들이 대기되는 상황입니다.
● RR (Round Robin) - FCFS + 선점(preemptive)
라운드 로빈(RR) 알고리즘은 FCFS 알고리즘이 양보가 가능한 선점형인 알고리즘입니다. 각 프로세스는 CPU가 주는 작은 단위 시간 Time quantum(시간량)을 받고 CPU 스케줄러는 Ready 큐를 돌며 프로세스에 타임 퀀텀만큼의 시간동안 CPU에 할당합니다.
타임 퀀텀이 너무 작으면 프로세스들을 Context Switch만 하고 너무 크면 다른 프로세스들이 미뤄질 수 있습니다. 일반적으로 타임 퀀텀은 context switch 시간에 1000~1만배 정도라고 합니다.
*경험의 법칙(Rule of thumb) : CPU Burst에 80%가 타임 퀀텀보다 짧다면 반환시간이 을 줄일 수 있다는 법칙이며, 이름이 경험의 법칙인 이유는 경험 통계로 얻은 규칙이기 때문입니다.
● SJF (Shortest Job First. 최단 작업 우선 == Shortest next cpu burst algorithm) - 비선점(nonpreemptive)
SJF 알고리즘은 가장 짧은 작업을 우선으로 할당하는 알고리즘입니다. SJF는 주어진 프로세스집합에 대해 최소의 평균대기 시간을 가진다는 점에서 최적임을 증명할 수 있다고 합니다. 하지만 현실적으로 각 프로세스에 CPU 버스트 길이, 즉 프로세스가 끝나는 시점을 알 수 있는 방법이 없기에 구현하기 어렵습니다.
● SRTF (Shortest Remaining Time First) - SJF + 선점(preemptvie)
SJF알고리즘의 경우 새롭게 들어온 job가 현재 job보다 짧더라도 현재 진행중인것을 내려놓지 않고 계속 진행합니다.
SRTF 알고리즘은 이와달리 새로 도착한 job이 현재 작업중인 job의 남은 시간보다 짧다면 교체합니다.
● Priority (우선순위)
우선순위가 정해져있고 CPU 코어는 가장 높은 우선순위를 가진 프로세스를 할당합니다. 우선순위가 같은 프로세스는 보통 FCFS, RR 방식으로 스케줄링 됩니다.
우선순위 스케줄링에 주요 문제점은 기아(Starvation)상태입니다. 기아 상태는 낮은 우선순위를 가진 프로세스가 영원히 실행되지 않을 수 있는 상태입니다. 한 루머로 MIT에서 1973년 IBM7094를 종료했는데 1967년에 제출된 우선순위가 아주 낮은 프로세스가 아직 끝나지 않은채 존재했다는 이야기가 있습니다...
해결 방법 중 하나로 노화(Aging)을 쓰는데노화는 오랫동안 대기한 프로세스의 우선순위를 높이는 방법입니다.
● Multilevel Queue (다단계 큐) - Priority + @
다단계 큐 방식은 Ready큐를 여러개의 큐로 분리하여 큐 사이에 우선순위를 부여하는 우선순위 스케줄링 방식으로 각 큐마다 다른 스케줄링 알고리즘을 적용하는 경우도 있습니다. 높은 우선순위를 무조건 먼저 실행할 수도 있고 큐에 따라 타임퀀텀을 가중치에 따라 배정할 수도 있습니다.(1순위 : 10초, 2순위 5초 ...)
아래 그림에서 실시간 프로세스의 경우 일반적으로 FCFS, RR을 사용합니다.
● Multilevel Feedback Queue(다단계 피드백 큐)
다단계 피드백 큐는 각 큐들을 CPU 사용량이나 특정 기준에 따라 큐도 우선순위를 이동할 수 있는 방식입니다. CPU를 너무 많이 사용했으면 내리고, 너무 오래 기다렸으면 올릴 수도 있습니다.
사용할 시스템에 알맞게 구성이 가능하여 가장 일반적인 CPU스케줄링 알고리즘이지만, 가장 복잡한 CPU 스케줄링 알고리즘이기도 합니다.
스레드 스케줄링
스케줄링의 단위가 프로세스였던 과거와 달리 현재의 리눅스, 윈도우, 맥과 같은 OS에서는 Kernel-level 스레드를 스케줄링의 단위로 인식합니다. 이는 Thread글에 "프로세스와 스레드에 대한 고찰"부분에서 결론적으로 리눅스는 두가지 모두 task로서 본다고 한 점과 같습니다.
Multiple Processor Scheduling (다중 프로세서 스케줄링)
비대칭 멀티프로세싱(asymmetric multiprocessing)이란 마스터 서버라 불리는 하나의 프로세서가 모든 스케줄링 결정, I/O 등을 도 맡아서 합니다. 이 경우 오직 하나의 코어만이 시스템 자료구조에 접근하여 제어하기에 간단하며 대신 마스터 서버가 전체 시스템 성능을 좌지우지할 수 있습니다.
대칭 멀티프로세싱(SMP : Symmetric MultiProcessing)이란 각 프로세서, 코어 본인이 스케줄링을 하는 방식입니다. 모든 코어의 스케줄링이 동일한 경우가 많으며 대부분의 최신 OS는 이 방식을 띄고 있습니다.
이때 스케줄링에 대상이 되는 스레드를 관리하기 위해 2가지 방식이 선택될 수 있습니다.
1. common ready queue : 모든 스레드는 공통 Ready큐에서 관리합니다. 이때 Ready 큐를 공유하기에 경쟁상태(race condition)이 발생할 수 있고, 이를 막기 위해 동기화 하는 Locking이 필요해서 성능 저하, high contention이 유발될 수 있습니다.
2. per-core run queues : 각 코어가 자신의 Ready 큐를 관리합니다. 가장 일반적인 형태로 cache의 성능이 좋은 반면 workload balancing 알고리즘이 필요합니다.
멀티 코어 프로세서
현대 컴퓨터 하드웨어는 여러 프로세서 코어를 한 물리적 칩에 배치하는 추세입니다. 각 코어는 구분되어 있어 OS 입장에서는 개별적인 논리 코어로 보입니다. (듀얼, 쿼드, 헥사, 옥타 코어 ...) 즉 일꾼이 여러명입니다.
멀티 스레드 코어
하드웨어 스레드란 OS가 코어에 스케줄링 해줄 수 있는 스레드 최소 단위입니다. 한 코어는 여러개의 하드웨어 스레드를 가질 수 있습니다. 세부 설명은 아래에 있습니다.
소프트웨어 스레드란 프로그램 상에 스레드입니다. pthread API를 이용해 스레드를 100개 만든다고 생각하면 여기서 코어, 하드웨어 스레드에 갯수와 상관없이 스레드를 무한히 만들 수 있습니다. 이는 실질적으로 코어에서 처리되고 있는 스레드가 아니라 task로서 어떤 작업을 할지 써놓은 스레드입니다. 이 소프트웨어 스레드는 스케줄링 되어 1개의 소프트웨어 스레드가 1개의 하드웨어 스레드에 할당됩니다.
Memory stall이란 CPU가 메모리에서 버스를 통해 데이터를 로드/스토어 하기 까지의 대기시간입니다.
다음은 설명 예시입니다.
쉐프는 매니저가 주문서를 전달해 주면 요리를 합니다. 쉐프가 만든 요리는 서버에 의해 서빙됩니다.
이때 요리가 끝나고 서빙을 하는 동안 생기는 대기 시간에 매니저가 다음 주문서를 전달해주면 쉐프는 바로 다음 요리를 합니다. 서빙시간 동안 요리가 완성 될 때마다 매니저가 주문서를 적절히 넣어주면 요리사의 작업량을 극대화시킬 수 있습니다. 쉐프는 한 사이클 동안 3개의 요리를 만들 수 있습니다.
● 쉐프= 코어
● 매니저 = OS 스케줄러
● 서버 = 메모리 버스
● 서빙으로 인한 대기시간 = Memory stall
● 서빙 사이 동시에 만들 수 있는 요리의 개수(3개) = 3개의 하드웨어 스레드
● 주문서 = 소프트웨어 스레드(n개 가능)
실제로도 코어는 계속 작업을 하고, 메모리를 가져오는 과정으로 쉬는 시간동안 OS가 스케줄링을 통해 다음 작업을 바로바로 계속 할당해줘서 코어가 쉬는 시간이 없게 만들어 만약 메모리 가져오는 과정동안 2개의 스레드를 추가로 처리할 수 있다면 코어는 3개의 하드웨어 스레드를 가지고 있는 것입니다.
이것이 OS 관점에서는 하나의 코어더라도 각 하드웨어 스레드는 별개의 명령어 포인터, 레지스터 집합과 같은 구조적 상태를 유지하기에 소프트웨어 스레드를 실행할 수 있는 논리적 코어(1코어 1스레드 처리하는)로 봅니다. 이를 칩 다중 스레딩(Chup Multi Threading)이라고 합니다. 인텔의 경우 하이퍼스레딩이(=simultaneous multithreading)이라고 명명합니다.
즉 일꾼이 여러일을 동시에 할 수 있습니다.
멀티 스레드 멀티코어 시스템
컴퓨터의 작업관리자를 보면 코어보다 논리 프로세서(코어)가 더 많은 것을 볼 수 있습니다. 현재 i7 -12700kf의 경우 코어가 12개 논리코어가 20개로 하드웨어 스레드가 20개인것을 알 수 있습니다.
아래의 경우 프로세서는 2개의 코어를 가지지만 각 코어가 2개의 하드웨어 스레드를 가지고 있어 OS View에서는 4개의 논리적 CPU로 보입니다.
코어 내에서 2개의 하드웨어 스레드가 스위칭을 하는 경우 instruction pipeline이 깨지므로 비용 증가가 있습니다.
각 코어는 하나의 하드웨어 스레드만 실행 가능합니다.
여기서 알아야 할점은 하드웨어 스레드가 병렬처리가 가능한 것이지 실제 코어가 여러개인 것은 아니라는 점입니다.
병행이 아닌 병렬처리이기에 하드웨어 스레드간에도 순서가 있고, 그렇기에 여러 소프트웨어 스레드를 OS가 스케줄링 해서 하드웨어 스레드로 보낼 것들을 가져오고, 이 하드웨어 스레드를 실제로 어떤 코어가 실행할지 결정해야 합니다.
즉
①소프트웨어 스레드 → 하드웨어 스레드 (OS가 보는 스케줄링 알고리즘 기반 관점)와
②하드웨어 스레드 → 실제 코어에서 작업(Chip, Core 내에서 발생하는 일)
2개의 다른 스케줄링 단계가 필요합니다.
일반적으로 ①은 여기서 소개된 모든 스케줄링 알고리즘, ②에서는 라운드 로빈이나 Dynamic urgency value 등이 쓰입니다.
Load Balancing (부하 균등화)
SMP 시스템에서 프로세서 여러개를 최대한 효율적으로 쓸려면 각 프로세서에 일(부하, Load)를 적절히 배분(Balancing)해는게 중요합니다. Load balncing은 각 코어가 자신만의 개별적인 큐를 가지고 있는 경우에만 의미가 있습니다.
일반적으로 Push migration 방식과 Pull migration 접근법이 있습니다.
Push migration : 특정 task가 주기적으로 각 코어의 부하를 검사하는 방식입니다.
Pull migration : 쉬고있는(Idle) processor가 자발적으로 바쁜 프로세서에 짐을 pull 해주는 방식입니다.
*Heterogenous Multiprocessing(HMP) : 모바일 시스템에서는 배터리 절약을 위해 성능이 떨어지는 동일 기능에 코어를 추가로 가지는 경우가 있고 이를 HMP라고 합니다.
Processor affinity (프로세서 선호도 = 캐시 선호도)
SMP를 지원하는 여러 OS에서는 스레드가 한 프로세서에서 실행되고 다시 실행할 때 이전과 동일한 프로세서에서 계속 실행시켜 캐시를 효율적으로 쓰려고 합니다. 이를 캐시 선호도라고 하고 작업 중이던 스레드는 프로세서에 선호도를 갖는 스레드라고 합니다.
약한 선호도(soft affinity)의 경우 OS가 선호도를 지키기 위해 노력하지만 타협할 수 있습니다.
강한 선호도(hard affinity)의 경우 OS는 선호도를 무조건 지켜주고 프로세스는 시스템 콜을 통해 자신이 실행될 프로세서 집합을 명시할 수 있습니다.
리눅스의 경우 강한 선호도를 지원하여 스레드가 생성될 프로세서를 지정할 수 있습니다.
실시간 CPU 스케줄링(Real-Time CPU Scheduling)
실시간 시스템(Real-Time system)은 '빠른 시스템'과 같이 속도에 대한 이야기가 아니라 '일정 시간 안에 보장된 시스템'에 대한 내용입니다.(real-time = time bound 안에 종료 O fast X) 그렇기에 실시간 시스템도 2가지 방식이 있습니다.
연성 실시간 시스템(Soft real-time system) : 중요한 실시간 프로세스는 가장 높은 우선순위를 갖지만, 스케줄링 되는 시점에서 반드시 '우선적으로' 실행된다는 것을 보장하지는 못합니다. 즉 OS는 노력하지만 보장하지는 못합니다.
경성 실시간 시스템(Hard real-time system) : Task를 반드시 일정 시간안에 완료되는게 보장되어야 합니다.
*경성 = 단단한 성질.soft, hard에 대한 번역이 다양한것 같다...
이벤트 지연시간(Event latency)
이벤트 지연시간이란 이벤트가 발생해서 그것을 인지하고 서비스를 시작할 때까지 지연되는 시간입니다.
일반적으로 두 가지 지연시간이 실시간 시스템의 성능에 큰 영향을 끼칩니다.
1. 인터럽트 지연시간(Interrupt latency) : CPU에 인터럽트 발생한 시점 ~ 해당 인터럽트 서비스 루틴(ISR) 시작 직전까지의 시간입니다.
2. 디스패치 지연시간 : 디스패처가 한 프로세스를 멈추고 다른 프로세스를 CPU에 전달하기 까지 걸리는 시간입니다.
디스패치 지연시간 충돌(conflict) 단계는 2가지 구성 요소가 있습니다.
● 커널에 동작하는 프로세스에 대한 선점
● 낮은 우선순위 프로세스는 높은 우선순위 프로세스가 필요한 자원 릴리즈.
우선순위 기반 스케줄링(Priority based Scheduling)
실시간 스케줄링에서 스케줄러는 선점, 우선순위 기반 스케줄링을 지원해야합니다. 단 이 경우는 soft 실시간 기능만 보장할 수 있습니다.
hard 실시간 기능을 보장하기 위해서는 실시간 task가 데드라인 안에 반드시 수행되는 것을 보장해야하고 이를 위한 다른 스케줄링 알고리즘이 필요합니다.
실시간 스케줄러는 우선순위 선정을 위해 프로세스의 주기, 마감시간, 수행시간 등에 특성을 활용합니다.
프로세스의 CPU 수행시간 = t, 마감시간 = d, 주기 = p (0<=t<=d<=p)
Rate Monotonic 스케줄링 - 정적 우선순위 정책(static priority policy) + 선점
Rate monotonic 스케줄링 알고리즘은 주기적인(periodic) 프로세스를 선점 가능한 정적 우선순위 정책을 통해 스케줄합니다. 이 알고리즘에서는 주기의 길이가 우선순위와 반비례합니다. 즉 주기가 짧으면 우선순위가 높게 배정됩니다.
컨셉은 CPU를 더 자주 필요로 하는 작업에 더 높은 우선순위를 주려는 방식이며, 정적인 우선순위를 사용하는 알고리즘 중 최적(optimal)인 알고리즘 입니다.
Rate monotonic 스케줄링 알고리즘은 N개의 프로세스를 스케줄링할 때 CPU 이용률이 N(2^(1/N) -1)을 넘기지 못한다고 합니다. N이 1인 경우 최대 이용률은 100%, N이 무한대인 경우 최대 이용률은 69%입니다.
아래 그림에 경우에도 CPU 이용률이 100%를 넘지 않지만 스케줄링이 불가능한 경우가 있습니다.
EDF 스케줄링(Earliest Deadline First Scheduling)
EDF 스케줄링은 이름 그대로 데드라인이 짧은 것을 동적으로 우선순위를 줍니다. EDF는 프로세스가 주기적(periodic)일 필요가 없고 CPU 버스트도 일정할 필요도 없습니다. 그저 스케줄러에 데드라인을 미리 알려줄 수만 있으면 됩니다.
EDF는 이론적으로 최적의 알고리즘이고 CPU 이용률을 100%까지 올릴 수 있습니다. 하지만 현실에서는 context switching 등 추가 비용으로 100%를 성취할 수는 없습니다.
실제 OS 사례
리눅스 스케줄링
*before 2.5 kernel ver
리눅스는 과거에 O(1) 스케줄링 방식을 썼으며 복잡도가 상수시간입니다. 우선순위는 가중치, 배정받은 타임 퀀텀과 비례하며 현재 실행중인 Active 프로세스와 쉬고 있는 Expired 프로세스들이 있어 Active가 다 완료되면 Expired와 스왑을 하는 버퍼 형태의 느낌에 스케줄링 이었습니다.
*after 2.6.23 kernel ver
현재 스케줄러는 CFS(Completely Fair Scheduler)로 완전 공정 스케줄러라고 합니다. CFS는 우선순위를 직접 할당하지 않고 가상 런타임(virtual run time)에 따라 동적으로 조정합니다. CFS는 runnable task 중에서 가상 런타임이 가장 작은것을 먼저 스케줄해줍니다.
CFS는 각 작업에 CPU 처리 시간인 타임퀀텀을 고정된 정적 시간이 아니라 CPU 처리시간의 비율을 할당합니다. 이 값은 Nice라는 값에 기반해 계산되는데 Nice 값은 -20~+19 범위를 가지고 있습니다. 작을수록 우선순위가 높습니다.
CPU 시간의 비율은 목적 지연시간의 값으로부터 할당되는데, 목적 지연시간(target latency)란 runnable task가 적어도 1번 실행되는데 걸리는 시간, 즉 모든 실행 가능한 task가 적어도 1번 실행할 수 있는 시간 범위를 뜻합니다.
CFS는 각 task별로 vruntime 변수에 task가 실행된 시간을 기록해 가상 런타임을 유지하고, 가상 런타임은 vruntime이 작거나 아예 1번도 안쓰거나, 새로 runaable task에 들어와 우선순위가 높은 애들이 우대됩니다.
같은 CPU 시간을 사용했더라도 우선순위가 낮은 프로세스의 가상 런타임은 높은 프로세스의 가상 런타임보다 크게 계산되어 우선순위가 나뉩니다.
Linux는 실시간 task와 일반적인 task에 할당해주는 우선순위 영역이 별도로 있는데, 실시간 task는 0~99 사이 범위에서 정적 우선순위를 갖고, 일반적인 task는 100~139까지 영역을 부여 받습니다.
위 Nice 값이 -20~+19인 것은 실제로는 100 <=> -20, 139 <=>+19로 매핑된 상태입니다.
학기 중에는 조금은 알 것 같다 생각했었는데 다시 조금씩 정리해보니 다른 글들도 보면서 정리를 더 해야겠다...
'강의 > OS' 카테고리의 다른 글
OS - 동기화 예시 (0) | 2023.07.17 |
---|---|
OS - 동기화 툴 (0) | 2023.07.16 |
OS - Thread (0) | 2023.06.29 |
OS - Processes (0) | 2023.06.27 |
OS - Structure (0) | 2023.06.26 |