0. Kernel preemption을 통해 urgent process를 normal process 보다 빠르게 수행할 수 있음.
1. Kernel preemption은 2.5에서 추가되었다.
2. Kernel preemption은 User land의 preemption과 다른 Concept.
3. Kernel preemption을 지원하기위해서 Kernel이 약간 수정되었지만, user land preemption 처럼 쉬운것은 아니었다. 커널이 single operation에서 certain action을 complete하지 못한다면 (data manipulation) race condition이 발생함. Multiprocessor system에서 발생하는 동일한 문제임. 이러한 문제점은 모두 SMP에서 모두 identify 되었음. SMP implementation에서 적용되어 재사용 가능.
4. Kernel이 선점될 수 있다면, uniprocessor system도 SMP와 같이 동작함
5. struct thread_info의 preempt_count를 이용해서 preempt될 수 있는지 tracking
6. preempt_count = 0 --> preemptable, >0 --> unpreemptable
7. preempt_count는 dec_preempt_count, inc_preempt_count를 통해서 값 변경
8. preempt_count를 Boolean value로 하지 않는 것은 critical section에 다양한 route로 접근가능하기 때문
9. Preemption 관련 보조 함수들
1) preempt_disable --> inc_preempt_count, memory optimization 회피
(kernel preemption mechanism에 문제 야기할 수 있기 때문)
2) preempt_check_resched --> scheduling이 필요한지 검사하고 필요하며 scheduling
3) preempt_enable --> enable kernel preemption --> preempt_check_reched
4) preempt_disable_no_resched --> disabling preemption (no rescheduling)
9. SMP system을 위해서 dec_preempt_count/ inc_preempt_count는 sychronization operation에 통합됨
10. (SMP <--> Kernel preemption의 차이) SMP에서는 per-CPU 관련 변수에 대해 protection을 할 필요가 없었지만, kernel preemption에서는 고려해야함. 왜냐하면 같은 CPU에서 다른 route를 통해서 그 값을 참조할 수 있기 때문임.
11. get_cpu, put_cpu는 kernel preemption을 disable 시킨다.
12. preempt_count vs. PREEMPT_ACTIVE
1) preempt_count는 다른 task가 kernel을 선점할 수 있는지 검사하기 위한 변수
2) 반면 PREEMPT_ACTIVE는 scheduler가 scheduling 호출이 선점에 의해 호출되었는지를 검사하기위한 flag
13. How does the kernel know if preemption is required?
0) preempt_enable -->
1) preempt_check_reched --> test_thread_flag (TIF_NEED_RESHED) -->
2) TIF_NEED_RESCHED flag --> CPU time을 요청한 process가 있음을 의미 -->
3) preempt_schedule : preempt_count > 0, irqs_disabled되었으면 just return
4) add_preempt_count(PREEMPT_ACTIVE) : scheduling요청이 preemption으로 부터왔음을 마킹
5) schedule : 선점에 의한 스케쥴링 요청일경우 deactivate_task를 건너뛰고 high-priority task가 스케쥴됨
14. kernel preemption이 trigerring되는 2가지 방법
1) preempt_schedule
2) preempt_schedule_irq
* preemption request가 IRQ context로 부터 왔음을 의미
* IRQ가 disable된 상태에서 call됨 (Simultanous IRQ에의한 recursive call을 방지하기 위함)
15. Low Latency: cond_resched --> long operation 중간중간에 call되어 다른 process가 동작할 수 있도록 해줌. preemption과 관계 없음