반복하지만 리눅스 커널 스케줄링은 다음과 같은 이유로 도입됐습니다.
"CPU에서는 한 개의 프로세스만 실행할 수 있다."
만약 CPU가 10개가 있는데 10개의 프로세스만 실행한다면 스케줄링 동작은 필요가 없게 됩니다.
그러면 다음과 같은 상황을 머리 속으로 그려볼까요?
"CPU에 A 프로세스가 실행을 하는 동안 B 프로세스가 대기 상태에 있다."
"CPU에서 A 프로세스가 실행을 마치면 실행 대기 상태인 B 프로세스가 실행을 시작한다."
이렇게 실행 대기 중인 프로세스가 한 개라면 얼마나 좋을까요? 이 방식대로 프로세스들이 동작한다면 리눅스 커널 코드는 지금과 같이 복잡하지 않을 것입니다.
하지만 실제 스케줄링 세부 동작을 살펴보면 이와 같지 않습니다.
CPU에 어떤 프로세스가 실행을 하는 동안 A 프로세스, B 프로세스, C프로세스 그리고 D 프로세스 등등 다수의 프로세스들이 서로 대기 상태로 기다릴 수 있습니다. 각각 프로세스들은 되도록 빨리 실행하고 싶어합니다. 서로 자신들의 우선 순위가 높다고 주장할 것입니다.
또한 여러 개 프로세스들이 동시 다발적으로 실행 요청을 합니다.
이 상황에서 대기 상태에 있는 프로세스를 관리하는 자료구조나 특정 메모리 공간이 필요하지 않을까요? 이런 역할을 런큐가 수행하며 다음과 같이 설명을 드릴 수 있습니다.
"런큐는 실행 대기 상태 프로세스와 CPU에서 실행 중인 프로세스를 관리하는 자료구조이다.
런큐가 여러 개 프로세스들로부터 실행 요청을 받아 관리를 해줍니다. 그래서 스케줄러는 런큐 자료구조를 이용해 스케줄링을 할 수 있는 것입니다. 여기서 다음과 같은 의문이 생깁니다.
" 그러면 '프로세스 스케줄링' 동작에서 언제 런큐 자료구조에 접근을 할까?"
먼저 프로세스 입장에서 생각해볼까요? 프로세스가 실행 요청을 할 때 다음 단계로 동작합니다.
"1단계: 프로세스 상태를 실행대기(TASK_RUNNING) 상태로 변경"
"2단계: 런큐에 Enqueue"
프로세스가 실행을 하려면 먼저 런큐에 '큐잉'을 하면서 자신을 등록해야 합니다.
런큐는 실행 대기 상태인 일반 프로세스를 프로세스의 태스크 디스크립터를 연결 리스트로 등록해 관리합니다.
이번에는 스케줄러 입장에서 언제 런큐에 접근하는지 알아볼까요?
"스케줄러는 대기 목록에 있는 프로세스 중에서 우선 순위가 가장 높은 프로세스를
다음에 실행할 프로세스로 선택!"
스케줄러는 런큐 자료구조에 접근해서 실행 대기 상태 프로세스를 확인해서 우선 순위를 고려해서 다음 프로세스를 선택하는 것입니다. 커널은 프로세스들이 생성할 때 프로세스의 택스트나 데이터 정보를 저장할 수 있는 태스크 디스크립터를 부여하는데, 런큐는 태스크 디스크립터 단위로 실행 대기 상태에 있는 프로세스를 관리합니다.
여기서 가장 중요한 의문이 생깁니다.
" CPU를 점유하면서 실행 중인 프로세스는 런큐에서 확인할 수 있을까?"
그러면 런큐 관점으로 스케줄링이 되어 프로세스 상태가 CPU 실행으로 변경한다는 의미는 struct rq curr에 저장된 프로세스 태스크 디스크립터 주소가 바뀐다는 것입니다. 즉, 런큐에서 실행 대기 상태로 연결 리스트에 등록된 태스크 디스크럽터 중 하나를 struct rq curr 필드에 바꾼다는 것입니다.
"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"
Thanks,
Austin Kim(austindh.kim@gmail.com)
Reference(프로세스 스케줄링)
스케줄링 소개
프로세스 상태 관리
어떤 함수가 프로세스 상태를 바꿀까?
스케줄러 클래스
런큐
CFS 스케줄러
CFS 관련 세부 함수 분석
선점 스케줄링(Preemptive Scheduling)
프로세스는 어떻게 깨울까?
스케줄링 핵심 schedule() 함수 분석
컨택스트 스위칭
스케줄링 디버깅
스케줄링 프로파일링
CPU에 부하를 주는 테스트
CPU에 부하를 주지 않는 테스트
# Reference: For more information on 'Linux Kernel';
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 1
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 2
최근 덧글