프로세스의 자발적 양보없이 언제든지 커널에게 선점당할수 있다는것을 의미합니다.

라고 말씀하셨는데요..

그런식의 해석은 지나치게 사전적으로 해석하신것이구요..

제가 쓴글의 내용을 조금 살펴보시면 되겠습니다만..

비선점형커널이 비자발적인 상황에서 CPU를 빼았기지 않는것은 아닙니다...

cpu 한개의 시스템에 비선점형 커널 커널이 동작한다고 가정합시다.

무한루프로 동작하는 프로세스를 만들면 이 프로세스에는

자발적으로 CPU를 반납하지 않지만 비선점커널은 다른프로세스로

일정한 규칙(스케줄링정책) 에 의거 CPU자원을 넘깁니다.

그럼 여기까지의 과정에서 과연 선점형 커널과 비선점형 커널에

무슨 차이가 있습니까?

오랜동안 몇가지의 커널 소스들을 직접 분석하고 공부했지만

여기까지 과정에서는 선점형 비선점형 커널간 구분은 의미가 없습니다.

인터럽트 처리 이외에 커널함수로의 재진입을 하는 케이스가 있나 싶습니다.

제 기억엔 없는듯한데...

바로 윗 글에 한해서는 결국 같은이야기를 서로 다르게 했다는 생각도 드는군요..

예전에 들었던 기억이 나는데, 이런거죠.

상황 : 한병의(CPU or Process 라고 가정) 술을 나누어 주는데

- 선점형 : 바텐더가 제어권을 가지고 술을 원하는 사람에게 나누어준다. 만약 그사람이 다운되어도 술은 계속 나누어 줄수 있다.

- 비선점형 : 바텐더가 아니고 1병의 술을 각자가 돌아가면서 따라준다. 이럴경우 술을 가진 1명이 다운되면 다른사람도 덩달아 술을 못마시게 된다는...

이런 이야기 입니다.

Linux는 앞의 것에 해당되지 않을까 합니다.
수고하세요.

무언가 큰 오해를 하고 계시군요. linux kernel이 선점형 kernel이다 비선점형 kernel이다라고 말하는 것은 user mode 상의 프로세스의 선점 유무로 판단하는 것은 아닙니다.

linux kernel이 선점형 kernel이다 비선점형 kernel이다라고 말하는 것은 kernel mode 상에서 선점되는가 선점되지 않는가에 따라 판단합니다.

그건 이전에도 말씀드렸듯이 kernel을 이루는 모든 코드가 선점 가능하게 작성되어야만 가능합니다.

무한 루프를 도는 kernel 모듈을 작성하셔서 2.4 kernel과 2.6 kernel에 각각 올려보십시요. 어떠한 현상이 벌어지나...
2.4 kernel은 시스템이 멎어버리는데 반해 선점 옵션으로 컴파일한 2.6 kernel은 insmod한 해당 프로세스만 멈추고 나머지 프로세스는 계속 동작할것입니다.

저 역시 리눅스를 포함하여 몇가지 kernel을 분석하였고 또한 1개의 GPOS와 1개의 비상용 RTOS를 개발하였고 그리고 지금은 상용 RTOS를 개발하고 있습니다.
분명히 말씀드리건데 선점형 kernel과 비선점형 kernel간에는 구분이 있습니다.

PS.
죄송합니다. 글을 다쓰고 난후에 보니깐 위에 쓰신 내용 추가되었군요. 저 역시 두분의 의견에 관점의 차이에 의해서 그런것이지 크게 다르지 않음을 말씀드리고 싶습니다.

제가 현재 보고 있는 문서가 이 주제와 관련이 있을지는 모르겠습니다.

문서는 인쇄를 했는데, 읽는 힘이 약해서 먼지만이 쌓여가고 있습니다.

여기에 보면 3가지로 process를 구분하더군요.

아직 스케줄링하는 부분을 읽지 못했으므로, 여기까지 쓰도록하겠습니다.

Different books on operating systems define a "process" in different ways, starting from "instance of a program in execution" and ending with "that which is produced by clone(2) or fork(2) system calls". Under Linux, there are three kinds of processes:

* the idle thread(s),
* kernel threads,
* user tasks.

-- 덧붙이는 글 --
참고가 되었으면 좋겠습니다.

http://www.faqs.org/docs/kernel_2_4/lki-2.html

 +-- 선점형 OS (linux) ------- 선점형 kernel (kernel 2.6 이후 optional)
 |                       |
 |                       +-- 비선점형 kernel (kernel 2.4)
 |
 +-- 비선점형 OS (windows 3.1)

어떤 분은 상위 트리에서 이야기하고 (손님)
어떤 분은 하위 트리에서 이야기하고 (질문자, jika님, anfl님)
전체 트리에서 잘 말씀하시는 분도 있고 (purluno님)

다들 내공이 대단하십니다. 마침 오늘 아침에 OS concepts 책에서 선접형과 비선점형 부분을 읽었는데.. 아무리 봐도 이상해서 궁금해 하던 찰나에 이 쓰레드를 읽고나서 조금 감이 잡혔네요..

책에서 읽은것을 요약해 보면
---------------------------------
1. Linux 는 user level 프로세스에 한해서만 preempt를 프로세스가 커널 모드에서 돌아가는 동안에는 preempt 당하지 않는다.

2. 리눅스커널은 user-level 코드에 의해 선점되지 않는다는 사실도 기억해야 한다. 커널이 이미 다른 프로세스를 위한 시스템 콜을 실행 중일때, 실시간 프로세스를 위한 인터럽트가 도착하면 그 실시간 프로세스는 현재 실행 중인 시스템 콜이 완료되거나 블록될 때까지 기다려야만 cpu 차지할수 있다.

3. 선점형 커널은 real-time 컴퓨팅을 위해서 쓰이는거 같습니다. 그런데 리눅스 같은 경우, 어떤 프로세스로 문맥교환 하려고 할때 그 프로세스는 system call 을 완료하거나 I/O blocking 이 발생하기를 기다려야 한다고 합니다. 그러면 dispatch 지연이 길어질수 있기 때문에 시스템 호출이 preemptive 되는 것을 허용할 필요가 있습니다.

3-A. 이것을 구현하기 위해서, system call 에 preemption point 를 삽입 하고, 그 호출이 높은 우선순위의 프로세스가 실행할 필요가 있는지 검사하도록 합니다.
만약 더 높은(즉, 더 급하게 처리해야 할 ) 프로세스가 있다면 문맥교환이 이루어 지고나서 system call 을 마저 처리합니다.

3-B. 다른 방법은 커널 전체를 선점가능하도록 하는 것입니다. 커널 자료구조가 꼬이는 것을 방지하기 위해서 동기화 메커니즘을 사용하여 자료구조를 일관되게 보존하면 됩니다.

p.s 저도 2~3년전에 OS,RTOS 수업을 들었고 리눅스 커널도 공부좀 했는데.. 머리가 나빠서 그런지 지금은 하나도 모르겠네요;; 흑

다들 말씀들을 잘 해주시네요...

그런데, 제가 알고 있기로는 Linux Kernel의 경우

Kernel Mode 동작 시점에 Interrupt Handler에의한

Kernel Control Path의 중첩은 얼마든지 일어날 수 있습니다.

즉, 예를 들자면 Kernel Module에서 무한 루프를 돌고 있다고

가정한다면, Context Switching은 결코 일어나지 않겠지만

Interrupt의 처리는 가능하다는 것이지요...

일단, 스케줄러는 타이머 인터럽트에 의해서 호출이 되는것으로 알고 있습니다.

만약에,

process A에서 fork() 시스템 콜을 수행 도중에,

timer interrupt가 발생을 한 경우,

비선점형인 경우엔, timer interrupt 핸들러는 fork()를 다 마친후에,

수행이 되겠죠?

반면에, 선점형인경우엔, timer 인터럽트 핸들러 처리를 하고, 스케줄링을

해버리게 되면, 일단, 다른 프로세스(process B)로 스위칭이 되고, 아까

process A의 fork()의 수행을 마친후에, process B를 수행을 하게 되는것인

가요??

부족한 부분있으면 조언 부탁드립니다.

오늘 하루에만 이쓰레드에 글이 참 많이 달리네요..

질문하신분의 마지막 글에 대한 답변입니다.

유저 프로세스에서 시스템콜 호출한 이후에

시스템콜 수행 도중에 인터럽트가 발생하는 상황을 전재로

선점형 커널인 경우 인터럽트 처리후 시스템콜로 복귀하고

비선점형 커널인 경우에는 일단 시스템콜을 먼저 수행한후에

인터럽트를 처리합니다.

유저모드 프로세스는 시스템콜과 인터럽트의 처리가 모두 끝난후에야만

수행될수 있다는 점은 선점형 비선점형 커널인 경우 모두 같습니다.

주제랑은 좀 동떨어진 이야기지만..

스케줄러의 호출에 관한 이야기를 좀 하자면

커널은 시스템콜이나 인터럽트 처리가 끝나면 스케줄러를 호출할지를 결정하는데...

needresched 라는 플레그를(리눅스의 경우입니다.) 확인해서 플레그가

세팅된 경우에만 스케줄러를 호출합니다.

플레그는 현재 수행중인 최우선순위의 태스크보다 더 급하고 중요한 유저테스크가 새롭게 존재하거나 타임슬라이스가 만료됬을때 세팅됩니다.

이런 이유로 스케줄러가 매 클럭인터럽트 마다 호출되는것은 아닙니다.

물론 그렇게 구현할수도 있겠지만..

클럭인터럽트 루틴은 시스템마다 틀리지만 1/100 초 내지 수만분의 1초마다 발생하기 때문에

클럭인터럽트마다 뭔가 작업을 복잡하게 하면 시스템 오버헤드가 엄청나게 증가합니다.

고로 일반적인 경우 클럭인터럽트 서비스 루틴은 그저 틱 값만 하나 증가시키고 종료됩니다.

타임슬라이스 세팅에 따라서 다르겠지만 10틱이 타임슬라이스로

세팅된 상태라면 클럭인터럽트가 10번 수행될때

스케줄러가 호출되겠지요..

아니 정확하게 말하면 해당 플레그가 세팅되고 결국 스케줄러가

호출된다고 해야겠습니다.

그 사이에 그보다 더 급한일이 있으면 그일을 해야 하기때문에

이러한 약간 복잡해 보이는 방식으로 스케줄링을 처리 합니다.

응답성을 높이기 위해서라고 하면 적당하겠군요...

언제든지 더 중요한 잡이 생겼을때 즉시 수행할수 있도록

최소한의 인터럽트 수행시간을 유지하는것이

커널 관련 프로그래밍의 기초라고 할수 있겠습니다..

kernel mode에서 인터럽스가 처리가 안 된다면,

cli()와 save_cli()는 왜 불리는거라고 생각하십니까 ? ^^

질문인지 딴지인지 의견표시인지는 모르겠습니다....

cli 를 이야기하시는것 보니

인터럽트 디스에이블이 뭔지 몰라서 질문하시는것 같지는 않은데..

제글이 인용되있어서...

제 글이 좀 이상했는지 모르지만

비선점형 커널에서 시스템콜 수행도중에는 인터럽트를 처리할수

없습니다. 시스템콜이 끝나야만 비로써 인터럽트 서비스루틴으로

점프가 가능해집니다....

만약 처리할수 있다고 생각하신다면 논리적으로 설명해주세요...

프리엠션 포인트 없는 시스템콜 루틴에서 cpu 제어권이 어떻게

인터럽트 서비스 루틴으로 넘어가는지 설명해주시면 제가 좀 생각해보겠습니다.

시스템 콜 수행중에도 (보통 top half 라고 생각하면 되겠지요?)
interrupt 요청이 들어오면 interrupt 처리를 먼저 하게 되어
있습니다. (interrupt라는 이름이 붙여진 이유이기도 합니다.)
그렇기 때문에 bottom half와의 shared data를 접근할 때에는
인터럽트를 off하여 synchronization을 보장합니다.
여기에 대해서는 위의 손님께서 언급하신 내용이 가장 정확한
거 같습니다.

제가 이해하고 있는 preemptive/non-preemptive 커널의
차이점은, 커널 모드를 수행중에도 스케줄러에 의한
non-voluntary context switching 이 일어날 수 있는가의
여부입니다. non-preemptive 커널의 경우에는, 한 프로세스가
커널 모드로 수행중일 때는 그 프로세스 스스로 sleep하는 경우
외에는 프로세스의 스케줄링이 다시 일어나지 않습니다.

다시 말하면 커널 모드에 있을 경우는 voluntary context
switching 만이 허용됩니다. 즉, priority가 더 높은 프로세스가
있더라도, 만일 어떤 프로세스가 커널 모드에서 수행중이라면,
커널 모드를 수행중이던 낮은 priority의 프로세스의 실행이
끝나기 전에는 (또는 sleep하기 전에는) context switching이
일어나지 않는다는 것입니다.

단, interrupt service routine은 프로세스 context를 가지지
않기 때문에 물론 수행은 됩니다. 그러나 interrupt 처리 후에는
다시 이전에 실행되던 프로세스로 돌아오게 되죠.

즉 앞에서 나온 'non-preemptive 커널에서, 무한 루프를 도는
커널 모듈'의 경우에는, interrupt service routine은 물론
수행될 수 있겠지만, 그 커널 모듈의 루틴을 실행하는 프로세스
외에 다른 프로세스로 context switching 을 일어나게 할 방법이
없기 때문에, 시스템이 죽었다고 말할 수 있는 것입니다.

preemptive 커널이라면 시간이 지남에 따라 무한루프를 도는
프로세스의 priority가 낮아질 것이고, 더 높은 priority를 가진
프로세스에 의해 '선점(preempt)' 될 것입니다. (context switch
가 일어납니다.) 따라서 시스템은 다른 일을 계속 수행할 수 있겠죠.

jika님.
딴지를 걸려고 한건 아니구요.
그냥 의견표시였습니다.

그리고, jika님뿐만 아니라 많은 분들이

kernel mode에서는 interrupt가 처리되지 않는다는 커다란 논리적 오류에 빠져 있는 듯해서,

kernel mode에서 interrupt가 우선적으로 처리된다는 증거를 가장 손쉽게 증명할 수 있는 함수인

cli()를 언급했습니다.

바로 위에 쓰신 손님이 가장 잘 정리해주신거 같습니다.

forhopes 님 "kernel mode에서는 interrupt가 처리되지 않는다는 "

제글 어디에 저런 말이 있나요..

제글 표현 하나하나 신경써서 읽어주시기 부탁드립니다.

시스템콜 "수행도중" 에 인터럽트를 처리할수 없다 라고

분명하게 그것도 여러번 적시 했습니다.

커널은 분명 인터럽트처리를 최 우선으로 처리해야 합니다.

당연한 이야기 이죠..

그걸 몰라서 장대한 댓글들을 달고 있는게 아니라는걸 알아주셨음 합니다.

그리고 위에 윗글에서 손님 아이디 사용하시는분은

비자발적 컨텍스트 스위치 이야기를 하셨는데요..

전체적으로 틀린 이야기 입니다.

시분할 시스템에서 커널모드에서 비자발적 컨택스트 스위치가 일어나지 않는 경우는 없습니다.

유저프로세스의 스케줄링과 선점형 커널 비선점형 커널 구분에는 영향이 없다는

설명 누차 했는데..

선점형 커널의 프리엠션 포인트 관련된 코드들을 좀 살펴 보시면 명확해지리라 생각합니다.

아울러 비선점형 커널에서 커널모드시 비자발적 컨텍스트가 일어나지 않는

커널을 지적해주시면 좋겠습니다.

스케줄링 정책과 선점 비선점형 커널의 구분은 연관이 없습니다.

jika님!

정확하게 기술하신 내용이 이해가 잘 안가서,

질문 좀 하겠습니다.

"일반적인 비선점형 커널은 일단 시스템콜 수행도중에는

인터럽트처리루틴으로 빠져나가지 않고 시스템콜 수행후에

인터럽트를 처리합니다. "

이렇게 글을 쓰셨는데,

이 말씀의 뜻은,

시스템콜의 시작과 끝 사이에는 인터럽트가 처리가 안 되고,

유저모드로 돌아간 후에 인터럽트가 처리된다는 뜻인가요 ?

시스템콜이라는 것은 유저모드에서 커널모드로 들어가는 것이고,

시스템콜의 끝은 커널모드에서 유저모드로 돌아간다는 뜻으로 쓰신 건가요 ?

정확한 의미를 알려주시면 의견 교환에 도움이 될 것같습니다.

그럼.

비슷한 이야기를 자주 반복하려다 보니까 본의 아니게 어조가 좀 강해지고 격해지는것 같습니다.

차분한 마음으로 다시한번...

forhopes 님..

비선점형 커널에서..유저모드에서 인터럽트를 처리하는것이 아니고요.

시스템콜을 처리하고 리턴프럼 시스템콜 할때 인터럽트가 들어와 있는지 확인해서 수행합니다.

(영어를 쓰는게 아니라 함수이름을 그냥 쓰는거니까 재수없게 생각은 말아주세요.. )

다시 말해서 시스템콜 수행후 유저모드로 돌아가기 직전에 수행한다고 하면 맞겠습니다.

선점형OS, 비선점형OS와 선점형Kernel, 비선점형Kernel 사이에서 용어혼란이 있는듯 싶군요.

저는 preemptive/non-preemptive kernel 이야기를,

jika님은 preemptive/non-preemptive OS 이야기를 하시는 듯합니다.

Linux 2.4까지는 non-preemptive kernel 이며 preemptive OS입니다.

Linux 2.6은 preemptive kernel 이며 preemptive OS입니다.

여기까지 맞나요 ?

linux 커널이 시스템콜에서 리턴 될 때만 인터럽트가 처리된다면,

cli()를 커널코드 작성시 사용할 이유가 없어집니다.

하지만, 실제로 linux kernel 소스를 보면 cli()를 무진장 씁니다.

cli()는 인터럽트 처리를 막도록 하는 함수입니다.

즉, 리눅스 커널에서는 강제가 인터럽트를 막지 않는한 시스템콜 처리중에도 처리된다는 뜻입니다.

저의 의견은 이러합니다.

조금만 노력하시면 자신의 의견을 검증하실수 있으실텐데요..

소스인사이트 같은걸로 리눅스 소스 검색해보면 님 말씀처럼

cli( 찿으면 수백개 나옵니다.

그중에 시스템콜이 있는지 비교해보세요..

시스템콜은 아래 문서에 요약되어있습니다.

http//tiger.la.asu.edu/Quick_Ref/Linux_Syscall_quickref.pdf

솔찍히 조금 짜증스럽군요..

딴지는 아니고요.

보다 정확히,
Linux 2.6은 Non-preemptive kernel 이지만, 커널 커피그레이션 설정을 통해 커널 컴파일시 선택적으로 preemptive kernel 로 만들수 있는 preemptive OS입니다.

Scheduling Policy 및 Algorithms에서 preemtive, non-preemtive를 빼버리면, 전산학(특히, 운영체제)의 많은 부분을 새로 써야 할것 같은데요?

선점형 커널이라는 단어와 선점형 OS 라는 단어를 구분해서 전체를 정리해주시려는 분들이 많군요..

두 용어를 구분하는건 제가 생각하기에는 적절치 않은듯 합니다.

굳이 구분하자면 선점형 커널 혹은 OS VS 선점형 멀티테스킹 혹은 선점형 스케줄링으로 구분해야 합니다.

두가지는 분명 다른 개념입니다.

후자의 개념 즉 선점형 멀티테스킹( 선점형 스케줄링은 ) 이라는 용어는

10~20년 전에 만들어진 개념이죠

당시에 시분할 시스템이 처음 도입되기 시작할때쯤 아마 이런 구분이 필요했을듯도 합니다.

하지만 현재 사용되는 임베디드 운영체제같은 자그만 OS 도 전부 다 시분할 시스템입니다.

비선점형 멀티테스킹을 한다는것 자체가 스케줄링을 거의 포기한것이나 다름없는데다가

응답성을 전혀 기대할수 없기 때문입니다. 수행되는 테스크의 수도 지나치게 많은 현실이구요..

그래서 현용하는 거의 전부의 운영체제는 시분할 시스템입니다.

다시 말해서 선점형 멀티테스킹 혹은 선점형 스케줄링을 말합니다.

고로 비선점형 멀티테스킹이니 비선점형 스케줄링이니 하는말은

50~60대의 나이드신 교수님이나 옜날책 가지고 컴퓨터 역사를 공부하는 학생들 한테나

의미가 있는 말이지 쓸모가 거의 없어진 개념입니다.

이 쓰레드 처음 만드신 질문자도 역시 이 개념을 기반으로 질문하신게 아닙니다.

여기에 올라오는 글들은 많은 분들이 오랜 시간동안 참고로 합니다.

저역시 이곳에서 좋은 정보를 많이 얻어가구요...

답글중에 전혀 사실과 다른내용이 있어서 정정하려 수차례 글들을 남기는데..

이과정에 좀 제가 잘난척한 꼴이 됬습니다.

죄송합니다.

여기 쓸만한 내용은 아니지만 커널관련 개발자가 이땅에서 격는 어려움이

어떤건지 아마 모르시는 분들이 많을겁니다.

로그인을 깜박하고 2005년8월11일 2:45 에 손님으로
글을 썼던 sangwoo입니다. :-)
jika님이 쓰신 글을 인용해서 이야기를 나누는 편이
명확할 거 같아서 그렇게 하겠습니다. 양해부탁드립니다.

cli가 system call 구현 안에 없는 이유는, interrupt가
일어났을 때, interrupt handler에 의해 수정되는 data
structure가 없기 때문이라고 생각됩니다만.

리눅스 커널 2.4.29의 sysinfo() syscall의 구현을
보시면 cli()가 있음을 알 수 있습니다.
그리고 수많은 device driver의 character device의 ioctl
루틴 역시 syscall의 구현이고, 아시다시피 수많은
cli()/sti()가 있습니다.

(참고로, 2.5부터는 SMP 향상을 위해 cli()/sti()는
사양길로 접어들었고, 다른 인터페이스가 권장되고
있으니, 논외로 하겠습니다. 잘 모르기도 하고.. :oops:
이 주제에 대해서는
http://imada.sdu.dk/~svalle/courses/dm14-2005/assignments/man/cli-sti-re...
를 보시는 것도 좋을 듯 합니다.)

그리고 보통 context switching이라고 할 때는
프로세스(커널 쓰레드 포함)간의 context 를 언급하는
경우가 많습니다. 리눅스처럼 interrupt가 process context
를 가지지 않는 경우에, interrupt context로 바뀌는 경우는
context switching이라고는 하지 않는 거 같던데요.

(참고로 FreeBSD 5이후부터는 interrupt가 process
context를 가집니다. spl()/splx()
(interrupt를 끄고 켜는 겁니다. 리눅스의 cli()/sti()와 비슷)
콜들을 없애고, mutex로만 synchronization을 통일하기 위해서입니다.
synchronization의 간편화/단일화라는 측면에서는
FreeBSD가 Linux보다 앞서 있다고 생각합니다. :-)
잠깐 딴소리였구요.

하지만 만일 이전에 interrupt되었던 프로세스가
커널 모드에 있었다면, 그 프로세스가 우선순위가
(당연히) 가장 높기 때문에 다시 스케줄됩니다.
커널모드에서 무한루프를 돌고 있었고, non-preemptive
커널이라면 당연히 이 루프를 빠져 나갈 방법이 없겠죠.

=======

원래 질문을 하셨던 분께...
User preemption, Kernel preemption은 구분되는
것이구요, 단지 '리눅스가 선점형인가 아닌가?'라는
질문은 여러 가지로 해석될 여지가 많습니다.
이 주제에 대해서는
Robert Love씨가 쓴 "LInux Kernel Development (2nd ed.)"
의 chapter 4의 user preemption과 kernel preemption항목을
보시는 것이 가장 명확하게 정리가 될 것 같습니다.
Robert Love씨가 Linux (2.6)의 Fully-preemptive kernel
을 구현한 사람이니까요. :-)

차분해지려고 했다가 다시 흥분했다가 오늘 정신병자된 기분이네요..

"시스템콜 수행중에는 인터럽트를 처리할수 없다"
"커널모드에서는 인터럽트를 처리할수 없다"

이 두 말에 차이를 이해 못하시면 대화가 곤란합니다.
커널 함수들 중에서 시스템콜이 차지하는 비중은 아주 작습니다.

인터럽트 헨들러와 시스템 콜을 혼용 하시는데요..

인터럽트 헨들러도 넓은 의미에서는 일종의

시스템콜이라고 할수도 있겠지만 상위에서 하위로 불러드린다는 개념에서는...

제가 두단어를 동시에 사용해왔기 때문에 두가지는 다른 개념으로

이해해 주셔야 합니다.

sysinfo() 에서 cli() 호출 한다고 하시는데 제가 그버전은 없어서

확인을 못해보지만 제가 확인한 커널에서는 2.6.11.10 에서는

cli() 호출하는 구문도 없고 그에 대응하는 다른 구문도 없습니다.

물론 님이 확인하신게 잘못됬다 이야기는 아니구요.

개인적으로 리눅스소스에서 불필요한 락이나 함수 호출을 수도 없이 봤기 때문에

저는 그정도로 이해하고 있습니다만 이 부분 가지고 님을 이해해시켜 드리지는 못할듯 합니다.

마지막으로

"커널 모드에 있었다면, 그 프로세스가 우선순위가
(당연히) 가장 높기 때문에 다시 스케줄됩니다. "

이부분도 틀린 말입니다. 아니 그렇게 구현하면 그렇게 될수 있겠지만

우선 리눅스가 그렇치 않고 다른 운영체제라도 그렇게 만들어서 좋을 이유가 없습니다.

정확하게 설명하면 커널 모드에 들어와 있는 동안에

더 중요하고 급한놈이 들어왔다면 니드 리스케드라는 프레그가

세팅 되어있을겁니다.

그런 경우를 대비해서 커널모드에서 벗어날때는 해당프레그를 확인해서

더 중요하고 급한놈이 생겼다면 해당 테스크로 컨텍스트 스위치 하고

그렇치 않다면 이전 테스크로 컨텍스트 스위치 합니다.

위에 이미 한번 설명한 내용입니다.

이 쓰레드에서 통용될수 있는 가장 핵심적인 단어는

응답성이네요... 쓰레드 답글 올라오는 속도도 빠르구요

이 글이 이 쓰레드에서의 저의 마지막 글입니다.

저는 원래 글로 누구를 이긴다거나 그런 생각 없이
단지 하신 말씀이 제가 알고 있던/있는것과 달라서
확인차 글을 남긴 것입니다. 어차피 이건 가치관이
들어가는 류의 논쟁도 아니고, 사실관계가 명확한
이야기이니 기분상해 하실 필요는 없을 것 같습니다.
저도 이 쓰레드 읽으면서 많이 배웠구요.

제가 말씀드린 것 이상으로 저는 제 생각을 설명드릴
능력이 없습니다. 제 능력의 부족 탓이겠지요. 아까
언급했던 Robert Love씨의 책에서 두 섹션만 발췌해서
번역해 적어 볼까 합니다.
(저작권 관련 문제가 있으면, 통지해주시면 삭제하도록
하겠습니다.)

Chapter 4. Process scheduling
o User Preemption
커널이 user-space로 return하려고 할 때
need_resched 가 세팅되어 있으면 스케줄러가 실행(invoke)
되고, 이때를 User preemption이 일어난다고 말한다.
커널이 user-space로 return하고 있다는 것은 커널의
상태가 (자료구조나 뭐 등등..) 안전하고 고요하다는
것이다. 다시 말하면, 현재의 task (프로세스나 thread에
해당하는 entity를 linux에서는 task라고 하더군요?)를
계속 수행하기에 안전한 상황이라는 것은 다른 task를
골라서 실행하는데도 안전하다는 것이다. 결과적으로,
커널이 user-space로 return하려고 준비할 때는, 그게
interrupt였든 system call이었든 간에 need_resched의
값이 체크된다. 그리고 만일 need_resched가 체크되어
있다면, 스케줄러는 새로운 프로세스를 골라서 실행한다.
<중략>
간단히 말해서, user preemption은
- system call로부터 user-space로 return할 때
- interrupt handler로부터 user-space로 return할 때
일어날 수 있다.

o Kernel Preemption
Linux 커널은 대부분의 다른 Unix variant를 비롯한
많은 다른 운영체제와는 달리 fully preemptive kernel이다.
non-preemptive 커널에서는 커널 코드는
수행이 완료될 때까지 실행된다. (kernel code runs until
completion)
따라서, 스케줄러는 어떤 task가 커널 모드에 있을 때는
reschedule을 수행할 수가 없다.
커널 코드는 선점적이 아니라, 협동적으로 스케쥴된다.
(kernel code is scheduled cooperatively, not preemptively)
커널 코드는 그 코드가 끝날 때까지(즉, user-space로
return할 때까지) 또는, 명시적으로 block할 때까지
(제가 이전에 언급했던 voluntary context switching에
해당합니다.) 실행된다.
그러나 버전 2.6에 이르러서 linux kernel은 선점식으로
되었다. (became preemptive) 이제는 커널이 reschedule
하기 안전한 상태이기만 하면 어떤 task를
어느 시점에서도 preempt할 수 있다.
그러면, 과연 언제가 reschedule하기 안전한 시점인가?
커널은 어떤 task가 lock을 hold하지 않는 한
커널에서 실행되는 그 task를 preempt 할 수 있다.
<중략>
Kernel preemption은
- 인터럽트 핸들러가 exit하고, kernel-space로 return하기 직전
- 커널 코드가 다시 preemptible 해 졌을 때
- 커널에서 실행되고 있는(== 커널 모드의) task가 schedule()을 call했을 때
- 커널에서 실행되고 있는 task가 block할 때 (결국 schedule()을 call하도록 된다.)
이런 경우에 일어날 수 있다.

User preemption과 Kernel preemption을 혼동하고
계신 분이 누구신지 잘 생각해 보셨으면 좋겠습니다.

윗분 인용하신책내용중에 첫번체 페러그렙은 제가 설명한 부분과 다르지 않은데

두번째 페러그렙은 제가 이 쓰레드에서 계속 해온 이야기와는 다른 이야기네요.

번역상의 문제인지 제 이해력이 부족한건지 모르겠습니다만..

실시간 프로세스를 제외하고 모든 유저프로세스는 커널 프로세스보다

우선순위가 낮습니다. 리눅스를 포함해서 대부분의 운영체제가 그렇쵸..

당연한 이야기 아닌가요?

그런데 커널모드에서 커널 프로세스 수행이 끝나지 않은 상황에서

일정 프리엠션 포인트마다 확인해서 유저프로세스로의 컨텍스트 스위치가 어떻게 일어날수 있다는건지 모르겠습니다.

그렇게 해서 얻을수 있는 이익도 없구요..

원칙적으로 인터럽트 수행이 밀리는것을 방지하기 위해서

프리엠션 포인트마다 인터럽트 수행여부를 확인하는것이 운영체제의

응답성 증대를 위한 페러다임에 부합하는 개념이라고 생각합니다.

더이상 이부분가지고 논쟁하고 싶지는 않구요..

윗분이 인용하신 두번째 페러그레프는 제가 잘못 이해한거라 생각하고 다른분들 판단에 맞기겠습니다.

본의 아니게 논쟁 비슷하게 되버렸는데요..

우리가 하는 일이 크게 보면 공대를 졸업해서 IT 관련업종에 종사하지만

모두가 다 똑같은 분야에서 메이저리티를 가지고 있는것은 아닙니다.

대학원 실험실에서도 그리고 지금 종사하는 회사의 연구소에서도..

수많은 사람이 있지만 다 서로 서로가 하는일이 다르고 잘하는 일이 다릅니다.

80여명정도 되는 작은규모의 연구소인데 서로가 서로 하는 일에 세미나라도

해주려 치면 크게 크게 넘어가지 않는한 세세하게 들어가면 이해시키기가 어려운 경우가 많습니다.

제가 커널 관련분야에 종사하다보니 하드웨어 하는 분들이나 제 윗단에서

작업 하는 분들하고 이야기 나눌때 답답한면이 많은데요..

물론 그분들도 저를 이해시키려고 힘들게 노력하십니다만...

가장 크게 문제가 되는게 책이나 문서를 보고 공부하는 경우와

소스코드를 분석하면서 공부를 하는 경우에서 오는 차이입니다.

누구나 자기의 주전공분야? 에서는 코드에 기초해서 공부하고 이해하고

내용을 만들어 나갑니다.

하지만 그 주변분야에 관해서는 책이나 문서로 채우지요..

잘못된 책이나 문서를 참조해서 문제가 되는 경우도 있겠지만

더 많은 경우에 책이나 문서를 만든사람의 뉘앙스와 그 책을 읽고 이해하는사람이 느끼는

뉘앙스가 다르다는 겁니다. 그런데도 불구하고 사람들은 문서와 책에서 본내용을 맹신 하거든요..

이쓰레드에 몇가지 잘못된 인용들이 그런 경우라고 생각합니다.

다행이 윗분이 인용하신 책은 용어사용이나 내용을 보아 좋은 책이라 생각됩니다만

그래도 역시 코드를 살펴보면서 이해하는것 하고는 다를수 있습니다.

물론 제가 모든운영체제의 소스코드를 다 외는것도 아니고 합니다만

이런 이야기를 하는 이유는 두가지 경우에 차이점이 분명이 있다는걸 말씀드리고자 함 입니다.

본의 아니게 남이 써놓은 이글 저글들에서 틀린 부분만 잔뜩 지적하고 갑니다만

서로 서로가 갖은 전문 지식을 서로나눈다는 본래 취지에서 크게 벗어난것은

아니니 너그러이 이해바랍니다.

본의아니게 거짓말을 한 셈이 되었습니다만, 시간이 갑자기
좀 생겨서 글을 올립니다. :-)

jika님의 글 잘 읽어 보았습니다. 좋은 말씀 감사드리구요.
저는 사실 Linux 커널을 살펴본 경험은 별로 없습니다만,
FreeBSD의 내부 구조에 대한 paper들과 문서들은 꽤 많이
읽어 보았습니다. 그렇다고 우려하신 것처럼 문서만 읽은
것은 아니구요, 이전에 다니던 회사에서 커널 프로그래밍의
경험도 있고, 현재에도 취미삼아서 디지틀 카메라를 위한
FreeBSD용 디바이스 드라이버를 작성중입니다. 제가
써 놓은 글들을 몇개 읽어 보시면 아시겠지만, 저도
코드를 보고 쓰는 사람입니다. :-)

어쨌든 제가 언급한 Robert Love의 책은 한번 꼭 읽어
보시길 권하고 싶습니다. 읽기 쉽게 쓰여져 있고, 여느
커널 책처럼 어이없이 두껍지도 않고요.. 그리고 pseudo code
가 아닌 실제 2.6.X의 소스를 갖고 설명을 합니다.

그리고 마지막으로 논의하던 내용 중 하나만 언급하자면,
Bach의 책을 비롯한 여러 OS나 컴퓨터구조 서적에도
언급되어 있듯이 (분명 인텔 CPU매뉴얼에도 있으리라
생각됩니다. 이건 집에가서 제가 확인하도록 하겠습니다.)
인터럽트 서비스 루틴은 절대로 시스템 콜 막바지까지
밀려서, 모았다가 실행되는 게 아니라, 발생 즉시 곧바로
실행됩니다. 그리고는 원래 컨텍스트로 복귀합니다.

FreeBSD 4->5로의 전환시에 성능이 엄청 떨어졌던 게
바로 이 이유 때문입니다. 자세한 내용은 다음 기회에
말씀드리기로 하구요. 어쨌든 이것만 다시 한번 확인해
주셨으면 좋겠습니다.

좋은 밤 보내세요. :D

"인터럽트는 발생 즉시 수행한다"

이런 문장 아마 수도 없이 많은책에 언급되어있을겁니다.

모두들 그렇게 믿죠.. 우상처럼...

그리고 그렇게 틀린말도 아닙니다.

하지만 개발자 입장에서 봤을때 저 말은 레절루션이 아주 낮은 상태에서만

맞는말이 됩니다.

보다 높은 레절루션에서 생각하면 저말은 아주 모호한 말이 됩니다.

전제가 아주 많이 붙어야 정확한 말이 되는거죠.

지금 잠시 언듯 생각해봐도 두세줄 이상 전제조건을 달아야만

정확한 표현이됩니다.

정확하게 이해하려면 특정 인터럽트 서비스 루틴을 콜하는 구문을 다 찾아서 살펴보면 됩니다.

좀 양은 많겠습니다만 여러가지 툴들을 이용하면 별로 어렵지 않게 찾을수 있습니다.

인터럽트 서비스 루틴이 무슨 전지전능한 신도 아니고 코드에서 콜하지 않았는데 수행될리 없습니다.

커널은 하드웨어를 쥐고 유저모드의 프로세스에 cpu 타임을 배정합니다.

인터럽트중에 비교적 우선순위가 높은 클럭인터럽트 수행을 (수정하지 않았다면 1/100초) 커널은 수행합니다.

클럭인터럽트 수행이후에 남는 CPU시간을 커널은 유저모드 프로세스에 할당합니다.

그런의미에서 인터럽트는 클럭인터럽트 발생주기보다 빠른 시간안에 반응 할수 없습니다..

여기에 사용되는 개념이 클럭인터럽트 레절루션입니다.

실시간 응답이 중요한 시스템에서는 클럭인터럽트 발생주기를 짧게해서

응답성을 높입니다.

CPU 성능에 따러서 다릅니다만 리눅스같이 덩치 큰 커널은 몇만분의 1초

이상 해상도를 높이면 클럽인터럽트를 오버헤드 때문에 시스템이 동작하지 않습니다.

클럭인터럽트를 수행하는 도중에 또 클럭인터럽트를 발생해야 하는 시점이 되서

결국 클럭인터럽트를 수행하지 못하고 까먹게 되는거죠..

덩치가 좀 작은 커널인 경우에는 수십만분의 1초 까지도 해상도를 높일수 있습니다.

그냥 제가 논문 쓰던때가 생각이 나서 끄적여 봅니다.

* preemption이란, 강력한 절대자가 있어서( 그 무엇보다 권위, 우선순위가 높은), CPU를 내놓지 않아도 강제로 방빼게 하는 것을 의미합니다. 이와 상대적인 것을 cooperative 스케쥴링(리눅스 2.4의 커널만 봤을때, 유저프로세스말고)이라고 부릅니다.

* preemption은 실시간 운영체제의 스케쥴링에서는 필수적인 요소입니다. 그러나, preemption을 구현했다고 실시간 운영체제가 되는 것는 아닙니다. 단지, preemption은 실시간 스케쥴링 전략을 구현하는 도구중 하나일뿐.

* 구지 실시간운영체제까지 갈필요없이, 운영체제 fundamental 수준에서 preemption은 또 다른 의미로 설명할 수 있습니다. 바로 데드락이 발생할 필요조건인데요. 아래 A,B,C,D가 A and B and C and D라는 얘기지요.
A. mutual exclusion
B. hold and wait
C. non-preemption
D. circular wait
데드락을 발생하지 않게 하려면?
이중 하나만 깨면 됩니다. 즉, 하나만 false로 만들면 deadlock은 절대로 발생하지 않는다는 것이지요. 이중 Not C는 preemption이 되겠군요. 특정 user process에서 무한루프에 빠졌다고 해도 돌 수 있는 것은 granularity를 높게 봐서 스케쥴링 단위를 커널(K), U1, U2,...Un으로 볼때, 임의의 Ui가 CPU를 점유하고 있을때, K가 이를 Preemption할 수 있다면 시스템은 무한루프/데드락으로 볼 수 없겠습니다. 그러나 K가 무한루프/데드락에 빠졌다면?...그리고, 이 일이 빈번할 수 있다면? 이런 커널이 있는가? 제가 보기에는 리눅스(2.4, 모듈들..!)가 딱이었습니다.

* 개인적으로 리눅스( 2.6.X)가 커널 레벨에 preemtive scheduling을 구현한 이유는 리얼타임시스템을 목표한다기 보다는, 커널모듈(디바이스 드라이버)의 오픈시스템 추구로 인한 부작용을 최소화하기 위함이라고 봅니다. 물론, 리눅스에 기반한(그러나, 손을 좀 많이 보는....) 실시간 운영체제들도 여럿 있고,
(비/실시간)마이크로커널, (비/실시간)나노커널등에서도 리눅스를 자신의 고유커널에 포팅하고자 한 노력들이 많이 있었습니다.

인터럽트에 대해 많이 아시는데, 그럼 다음을 정리해 주시지요.
1. S/W Interrupt
2. H/W Interrupt
- maskable interrupt
- non-maskable interrupt
3. Exception
- trap
- fault
- abort
4. defered interrupt

jika 님 말씀에 수긍이 갑니다.

실제로 시스템 클록의 레졸루션은 대단히 낮지 않나요...

일반 오에수 교재에서 언급하는 말들은 이상적인 가정,

즉, 인터럽트의 발생 시점을 아날로그적인 해상도로 간주했을 때 이야기인것 같습니다.

시스템 클록의 레졸루션 한계로 인하여 인터럽트의 중첩 및 대기는 필수적으로 발생한다고 생각합니다...

아참 그리고 이 이야기는

제 생각이 아니고, advanced operating system concepts에서 나온 이야기 입니다.

거시기 실바스까츠가 쓴 책말입니다.

정확히 인터럽트의 대기에 관해서는 언급이 없지만, 시스템 클록의 낮은 해상도는 명확히 문제삼고 있습니다.

그리고, 이 스레드에서 정말 많은 걸 배웠쓰미다..

특히 클럭 레졸루션에 관한 jika 님 설명은 제가 도무지 찾을 엄두를 못내고 있었는데... 너무 쉽게 설명해 주셔서... 감사드립니다..