계속 헷갈리는 개념입니다. ㅠ;
다음은 프로세스 context와 인터럽트 context에 대해서 정리한 것인데 맞는 건가요?
프로세스 context 영역에 대해서 다음과 같이 생각을 할 수 있을 것 같습니다.
1. 유저 모드이며, 유저 code에서 명령어를 fetch 하여 실행하고 있는 상태
2. 유저영역에서 시스템 콜로 커널로 진입 하여 커널 code를 fetch 하여 실행하고 있는 상태
(프로세서가 요청한 작업을 커널이 대신 수행하고 있는 상태)
인터럽트 context영역
1. 프로세스 context와 상관없는 인터럽트 핸들러와 bottom half를 위한 영역
따라서 인터럽트 받을 때 stack쌓으면서 실행하다가 그 인터럽트가 끝나면 사라지고, code는 그대로 있을 것 같습니다.
(구체적으로 어떤 자료형이 유지되고 사라지는 걸까요>?)
댓글 5
-
홍문화
2011.04.25 16:13
-
김윤기
2011.04.26 09:47
bottom half도 인터럽트 context안에서 실행되어질 수 있는걸로 알고 있습니다. 물론 프로세스 context안에서 실행될 수 도 있고요 context라는게 현재 CPU상에서 실행되는 코드의 정보(?)를 뜻하는 걸로 알고 있습니다. 이 정보에는 각종 연산에 필요한 레지스터, 현재 사용중인 스택의 위치를 나타내는 스택포인터, 프로그램 카운터 등등이 있고요. 예를 들어 프로세스A,B,C 가 있을경우 CPU가 현재 프로세스 A를 실행하고 있으면 프로세스 A context에 있다라고 보면 되는 거죠 여기서 프로세스 B를 실행할경우 프로세스 A에 관한 정보를 저장할 공간이 있어야겠죠..? 리눅스에서는 context를 저장할 공간을 커널 스택에 두는 거죠.
즉 프로세스 A 실행 -> 커널스택에 프로세스 A에 관한 context 저장 -> 프로세스 B에 관한 context를 CPU에 읽어들임 -> 프로세스 B수행 요런 작업을 하겠죠..?
여기서 인터럽트 context도 프로세스 context와 마찬가지입니다만 프로세스 context와 다른 가장 큰 특징은 휴먼하지 않는다는 점을 들 수 있겠네요. 아 그리고 인터럽트 context의 context의 정보는 인터럽트가 호출된 시점의 프로세스의 커널스택(아키텍처에 따라 인터럽트 전용 스택)을 쓴다고 그러네요
즉 프로세스 A가 수행중에 인터럽트가 발생하면 프로세스 A의 커널스택위에 인터럽트의 스택이 쌓이는 거겠죠..?
< kernel stack>
--------------------
interrupt handler
--------------------
process a
--------------------
요런식으로요. 그리고 bottom half가 인터럽트 핸들러 종료후 바로 실행된다면
--------------------
bottom half(ex softirq)
--------------------
process a
--------------------
요렇게 되겠죠. 이상태는 아직 프로세스 context로 넘어가지 않았으니깐 인터럽트 context에 있다고 보면 되지 않을까 싶습니다. 그리고 프로세스 context에서 실행되는 bottom half로써 워크큐가 있네요.
결론은 bottom half는 그때 그때 다른다입니다.
비오는날 습자지 같은 지식으로 혼란을 드릴 수 있으니 반드시 확인해 주세요 T_T
혹시나 틀린점은 바로바로 수정해 주시고요. 저도 뭐 공부하는 입장이니깐요 ㅋ
-
김윤기
2011.04.27 00:43
다음 스터디에서 context에 대해 토론해 보는 시간을 갖는 것도 좋을 듯 합니다.
context 와 context switching, dispatcher 등등에 관해서요 ㅎ
-
신창호
2011.04.27 15:48
두번빠졌더니... 쫓아가기 힘들군요...
-
박재성
2011.04.29 15:32
저도 이쪽 부분을 이해하는데 어려움이 있었는데 위의 정리된 내용을 보니 좀 정리가 되네요.. ^-^ 설명 감사합니다.
.
인터럽트 핸들러에서 사용하는 지역변수가 8KB 프로세스 커널 스택, 또는 4KB 인터럽트 전용 스택에 생겼다 사라지겠죠.