리눅스 2.6 스케줄링 및 선매 - 선취 계산 사용

Question

질문 앞에 약간의 토론. Linux 2.4 커널은 우선 순위가 낮기 때문에 커널 모드에서 시스템 호출을 처리 할 때 컨텍스트 전환이 필요한 경우 set_need_resched를 수행하여 플래그를 발생시킨 다음 사용자 모드로 돌아갈 때 플래그를 지정하고 컨텍스트 전환을 수행하십시오.

선점 형 커널이있는 Linux 2.6과 비교해보십시오. 2.4의 커널을 가져 와서 set_need_resched (발생 플래그)를 schedule() (다시 스케줄의 지시 실행)로 변경할 수 없습니다. 따라서 Linux 커널 2.6에서는 spin_lock()에서 매번 증가하고 감소하는 카운터 preempt_count가 있습니다. on spin_unlock().

실제로이 필드 "preempt_count"는 커널을 선점 할 수 있는지 여부를 결정합니다.

(current->need_resched == 1) && (current->preempt_count == 0) 

해당하는 다음 커널 콘텍스트 스위치를 실행한다 : 클록으로부터 복귀에 예를 들면 조건 경우 인터럽트.

질문은 Linux 2.6 커널이 스핀 록 유형 잠금이 유지 될 때 선매를 방지하는 이유입니다.

커널이 선점을 막지 못한 경우에 발생할 수있는 시나리오는 무엇입니까? 할 수있는 한 세부적인 예를 들어 줄 수 있습니까?

감사합니다.

Answer 1

뮤텍스 또는 세마포어와 같은 잠자기 가능 잠금 장치에 대해 읽으셨습니까? 이들 경우에, 로크가 취해질 수 없다면, 스레드는 자신을 슬리 프 (sleep) 상태로 놓을 수있다. 자물쇠 소유자 (잠자는 경우)가 작업을 더 빨리 완료 할 수 있도록 우선 순위를 부여합니다. 특히 자물쇠를 취하고 자하는 스레드가 CPU에서 실행되어 자물쇠 소유자가 계속 예정되어있을 가능성이 있습니다.

반면에 스핀 록은 아무도 잠들지 않는다는 것을 의미합니다. 즉, 바쁜 대기 (즉, CPU에 머무르는 것)가 잠금 소유자를 차단하지 않는다는 것을 의미합니다. 자물쇠가 열리면 소유자가 어딘가에서 움직이고 있습니다. 그러나 그것이 자러 갔다고합시다. 이것은 대기 스레드가 소유자가 다시 일할 수 없기 때문에 시간 낭비를 의미합니다. 스케쥴러가 충분하다고 결정한 후에 만 ​​선점 될 것이지만 웨이터와 소유자 간에는 아무 관계도 없습니다. 따라서 특히 잠긴 사람이 계속해서 기회를 얻지는 않았지만 웨이터가 CPU를 다시 사용하여 바쁜 대기를 계속할 수 있습니다.

적어도 성능면에서는 큰 문제가됩니다. 실제로는 커널이 높은 진보를 할 수없는 고부하 상황에서 라이브 록으로 이어질 것입니다.