git 오류

android/kernel/: discarding 6 commits removed from upstream
project android/kernel/

It seems that I cannot create a rebase-apply directory, and
I wonder if you are in the middle of patch application or another
rebase.  If that is not the case, please
        rm -fr /home/yongk.kim/cayman_gb_mpcs/android/kernel/.git/rebase-apply
and run me again.  I am stopping in case you still have something
valuable there.

Context Switch

Context Switch (문맥 교환)

I. Context switch 이해



가. 문맥교환의 정의
- Running 상태의 Task가 사용하던 context를 메모리 특정 영역에 저장한 후 새로이 수행될 Task의 context를 PCB 또는 Stack 에서 CPU의 레지스터 영역으로 복사하여 새로운 Task가 수행되도록 하는 일련의 작업

나. 관련 개념
- Dispatching : 준비 상태의 프로세스들 중에서 우선순위가 가장 높은 프로세스에게 CPU 할당
- Time Quantum : 특정 프로세스에게 할당되는 시간의 단위, 특정 프로세스의 CPU 독점 방지
- Preemption : 타임 퀀텀이 초과하면 인터럽트를 통해 CPU 사용권을 빼앗음

II. Context switch 개념도 및 진행과정

가. 개념도
 

 
나. 진행과정 


1) 인터럽트나 시스템 호출에 의해 문맥교환 요구
2) 사용자모드 -> 운영체제 모드
3) 기존 프로세스의 현재 HW상태 정보를 PCB에 저장
4) 다음에 실행할 프로세스의 상태 정보를 PCB에서 복구한 후 다음 프로세스를 실행
5) 운영체제 모드 -> 사용자 모드

III. Context switch 과정의 오버헤드와 해결방안


가. 오버헤드 발생시점

 
 나. 해결방안

- Context Switch가 자주 발생하지 않도록 다중 프로그래밍 정도 낮춤
- 스택 중심의 시스템에서는 스택 포인터를 변경하여 프로세스간 문맥교환 수행
- Light weight 프로세스인 스레드를 이용하여 Context switch 부하 최소화 

Spin lock, live lock, dead lock

Spin lock 

크리티컬 섹션이 있고, 한 스레드가 크리티컬 섹션에 대한 lock을 소유하고 있다면 그 lock이 반환될 때 까지 계속 확인하며 기다리는 것을 의미(컨텍스트 스위칭을 하지 않고 루프를 돌면서 재시도 하는 것, Busy waiting)한다. Lock-Unlock 과정이 매우 짧아서 lock하는 경우가 드문 경우에 유용하다.

 

장점 : 잦은 컨텍스트 스위칭을 줄여서 효율을 높일 수 있다.

단점 : Lock이 길게 유지된다면 나머지 blocking 상태의 쓰레드들이 계속 무한루프를 돌아 CPU를 쓸데없이 낭비하는 경우가 생길 수 있다. 

 

Live lock

2개 이상의 쓰레드가 다른 쓰레드의 행동에 영향을 받으며 진행되는 경우, 쓰레드간의 신호가 서로 맞지 않아 신호가 맞을 때까지 진행하지 못해서 마치 행동은 일어나지만 block된것처럼 보이는 현상을 말한다.

좋은 예시를 들자면 한 길을 지나가는데 마주보는 사람이 서로 같은방향으로 계속 비켜줘서 지나가지 못하는 경우를 들 수 있다.

Dead lock

2개의 쓰레드가 동시에 lock을 건 상태에서 서로 lock이 풀리기를 기다리는 상황을 말한다. 이렇게 되면 작업이 진행되지 않고 영원히 기다리게되는 문제가 있다.

[출처] Spin lock, Live lock, Dead lock|작성자 쿨랜드