[운영체제] 3. 프로세스 & 스레드(4.8/5)

2.4.6 스레드 스케쥴링

사용자 레벨 스레드 : 커널은 스레드의 존재를 인지 못하여 프로세스를 선택하고 할당시간만큼 프로세스에 cpu제어를 넘김.

커널 레벨 스레드 : 커널이 스레드를 선택하여 실행

차이점 : 성능(a>b) -> 스레드 문맥교환을 하려면 메모리 맵을 바꾸고 캐시를 무효화 하는 등의 동작 필요. But 커널 레벨 스레드에서는 한 스레드가 I/O에서 대기하는 경우 프로세스 전체를 중단시키지 않음.

 

2.5

전통적인 유닉스 스케쥴링은 그룹 개념이 없으며 1초에 한번씩 스케쥴링, 선점, 밴드(우선순위)로 나누어서 스케쥴링. 실제 계산할 땐 CPU시간을 반으로 줄이는 방법을 사용.

한 번 실행시키면 cpu시간을 증가시키니 우선순위를 낮춤. 반으로 줄이는건 우선순위를 높여주려고.

 

프로세스를 밴드 단위로 나눔. swapper이 주기 스케쥴러. 가장 우선순위가 높음. 

BSD는 프로세스가 많아지면 금방 decay(실행 시간이 오래된 프로세스의 우선순위를 높여주는 기법)가 0이 되니까 로드 에버리지(실행중인 프로세스의 개수)를 기준으로 decay를 설정

 

 

실제 스케쥴링 알고리즘

피포와 RR은 리얼타임 프로세스.

피포는 D C B A순. 라운드 로빈으로 하면 D B C 후에 타임퀀텀만큼 B C를 반복하고나서 A를 스케쥴링

나머지는 전부 OTHER 정책에 의해 스케쥴링.

 

계산 하기 싫어서 비트맵을 가져왔다. -> 0~99 : 리얼타임, 100~139 : 아더

-> 상수 시간만큼 걸린다.

 

위는 Io-bound process에 높은 우선순위를 주는 정책.

nice값 : 고정된 우선순위

인터액티브 : 대기시간에 따른 우선순위

 

 

nice 값이 작은(high priority) 프로세스는 timeslice를 증가시켜 CPU를 더 많이 할당받을 수 있습니다. 

nice값을 기준으로 타임슬라이스를 할당, 나이스값이 0이면 100ms를 가짐. 20이면 20.

따라서 나이스값에 정확히 비례해서 할당되지 않음. 0하고 1일땐 5%차이, 18과 19는 2배 차이.

 

적절한 인터럽트 타임을 잡아야하는데, 비율 차이가 너무 많이 나서 타이머틱을 설정하기가 어렵다.

 

또한 타이머틱과 타임슬라이스 사이 정밀도 문제 발생. -> 인터럽트(타이머틱) 

그리고 인터랙티브 태스크에 너무 많은 호의를 줌.

 

2.4~2.6까지 O1을 쓰다가, rsdl -> 이후 CFS를 천재 인고 몬라가 개발 : 정확하게 비율만큼 실행,run queue를 없애고 RB tree사용

Nice to weight 라는 테이블을 만들어서 테스크들이 정확하게 웨이트에 비례하여 CPU시간을 할당받을 수 있도록 함.

내 비율(중요도)에 걸맞는 양의 시간을 가져가야한다.

그래서 V-runtime이 의미하는건 weight대비 가상의 실행 시간. -> 공정한거다!

 

여기서 생각해봐야 할 문제 : 먼저 프로세스나 테스크의 v-runtime 값을 얼마나줘야 하는가.

io요청하고 깨어나면 브이런타임 값을 얼마나 줘야 하는가.

 

 

UNIX SVR4 : 옛날 것 : 선점 가능한 정적 우선 순위 스케쥴러

선점 포인트(preemption point = system call '도중에' 스케쥴링 하는 지점 -> 원래는 불가능)를 중간중간에 넣어 스케쥴링을 자주 하도록 만듦.

리얼타임 프로세스나 인터랙티브 프로세스가 스케쥴링을 빨리 받을 수 있는 효과를 갖게 됨.

 

real time 우선 -> 커널 -> time-shared순.

dispatch queues가 매달려 있으며, 비트맵이 존재.

 

Windows 스케쥴링

Windows는 우선순위 32개 존재, 상위 16개는 리얼타임, 나머지는 일반.

우선순위 기반 선점 스케쥴.

스레드가 만들어지면 상위는 리얼타임, 하위는 일반 프로세스 -> 하위를 기준으로 만들어짐.

기본 우선순위가 4로 할당되고, 위아래로 +-2까지 해서 우선순위 지정 가능.

실제 스케쥴링시 동적으로 우선순위가 2~15로 변하면서 스케쥴링.