X-window 와 리눅스 커널..

채소 wrote..
안녕하세요

문득 X-window with KDE 3 를 쓰면서

느리다! 라는 생각이 들더군요 윈2000 보다..

아직 fluxbox에서 벗어나질 못해서 KDE 3를 못 써봐 모르겠네요. -)
그런데 그거 아시나 모르겠군요. Windows 2000은 한달간만 빠르다는걸...
왜인질 모르겠지만 한달이 지나면 속도가 엄처 느려지더군요. 처음 설치
할 때와 한달 후에 설치되어 있는 상태가 똑같아도...
아마 깔린지 오래되면 OS가 늙어서 그런현상이 발생하지 않나 생각을
합니다만... -)
보통 GUI 를 구현하게 되면 백그라운드에 있는 어플리 케이션은 그리지 않는다거나 보이지 않는 프로세스 들에겐 priority 를 줄인다거나 하는 스케쥴 정책을 할거 같습니다(실제로는 더 복잡하겠죠..) GUI에서 실행되는 모든 프로그램들은 백그라운드로 실행이 되는겁니다.
정책에 관련된건 GUI뿐만 아니라 CUI에서도 같은 맥낙에서 동작을 합니다.
즉, 쉬고있는 프로세서는 그만큼 관심을 덜끌게 되고 스케쥴에서도 그렇게 하고 있을
것이라고 생각을 하지만...

리눅스 커널에 gui 가 들어있지 않아서 커널을 잘 모를테고 X 가 그런작업을 해야 할텐데.. X 에서 그런것이 제대로 구현이 되어 있는지 궁금하네요 X자체가 그런 일을 하는건 아닙니다.
모든 동작은 OS에서 결정을 하게 되어있습니다.
MS-Windows의 OS는 MS사에서 만들어낸 선점형 멀티태스크가 됩니다. 즉, 응용 프로
그램이 실행권한을 쥐고 있고 OS는 단지 응용 프로그램을 넘겨주는 권한을 다음 프로
그램으로 넘겨주는 역할을 할 뿐이죠.
물론 NT, 2000으로 넘어가면서 이 선점형에 문제가 많다는 것을 알고 비선점형(이
말도 MS에서 만들었죠.) 형태로 바꾸기는 했지만요.
하지만 비선점형(MS 98이전 OS이외의 OS들)도 완전한건 아니죠.
가끔 프로그램이 폭주를 해버리면 대책은 없죠. 폭주하는 원인 제공은 소프트웨어에서
기인 결국은 하드웨어적인 문제죠.
보통 스케쥴러는 timer에 의해서 동작을 합니다. 이건 인터럽트중에서도 중요 인터
럽트고 절대적으로 발생하게 되어있어서 가장 신뢰를 할 수는 있지만 사운드카드 충돌
, 프린터 통신이상 등 하드웨어가 직접적인 원인이 된다면(즉, 소프트웨어에서 제어
를 넘긴 즉시 무언가가 잡고 있다면...) 먹통이 되기는 마찬가지죠.
절대적인 OS는 없다고 생각합니다.

제가 추측하기엔 nice 같은걸로 줄이고 머 그럴거 같은데.. nice는 초기 실행시에만 주어지는 옵션입니다. 실행시에는 OS에서 판단을 내리게
되어있죠. 초기 커널에서는 공평하게 나누어준걸로 알고 있는데 지금은 어떻게 판단
을 하고 있는지 모르겠군요.(아마 그리 변하진 않았을 거라 생각됩니다.)
또 GUI 가 커널에 들어가지 않아서 생기는 단점 같은게 없을까요? 단점이라...
End User입장에서는 분리되어있는 듯한 느낌을 받는다는게 단점일까요?
단점을 찾으려면 많이 있겠죠. 그렇다면 붙어있는 것에 장점은 뭘까요?
그게 단점이 되진 않을까요? -)