SMP 커널에서 나타날 수 있는 Clocksource tsc unstable 현상에 대한 이야기.

오래간만에 오네요. 며칠 전에 블로그에 썼던 글인데, 시원찮은 내용이지만 혹시 다른 분들께 도움이 되지 않을까 싶어 긁어붙여 봅니다. -ㅁ-;

----

문제의 발단은 제가 쓰고 있는 Kernel 2.6.25로 갈아타면서, 이래저래 쓰다보니까 어느 순간 시스템이 굉장히 느려지는 현상이 보이더랩니다. 심지어 beep음의 길이가 삐이이이이이- 하고 길어집니다. 하지만 시스템이 완전히 멎지는 않더라구요.
(주: 경우에 따라, clocksource를 갈아치우면서 시스템이 멎는 현상이 발생할 수도 있습니다.)

이 건 뭥미? 싶어서 dmesg를 확인했을때 봤던 메시지는 "Clocksource tsc unstable (delta = ..)" 였습니다. 흠, 2.6.25의 버그인가, 싶어서 2.6.24로 다시 내리고 줄창 켜놓고 사용하다보니 그런 문제가 보이지 않길래, 2.6.25의 문제인가 보다.. 라고만 여기고 그냥 넘어가고 있었습니다.

그렇게 2달이 지났지요. 집에서 컴퓨터를 하는 시간이 짧다보니.. 그냥 자연스럽게 넘어갔었더랩니다.

며칠전에 2.6.26으로 갈아타면서, 올려놓고 쓰다보니 또 그런 현상이 보이더라구요. 그래서 이대로는 안되겠다 싶어 이래저래 해결해보기로 시도했습니다.

두서없이 구글링을 하면서 [2]의 문서를 읽게 되었고, 대충 간추려서 원인을 살펴보자면.. 다음과 같습니다.

클럭을 기준으로 tick이 올라가는 TSC[1]의 특성상 클럭을 변화시키는 CPU frequency scaling(AMD의 Cool'n'Quiet나 Intel의 SpeedStep과 같은)을 사용하면 시간의 흐름 간격이 틀어질 수 있습니다. 쉽게 말하자면 컴퓨터의 시계로 나타내는 1초가 현재 클럭 수에 따라 달라질 수 있다고 설명할 수 있겠습니다. 덕분에 실제 시간과 격차가 점점 벌어질 수 있겠지요.

RTC(Real Time Clock)에 비해 사용시 오버헤드가 작고, 또한 resolution이 높은터라 TSC의 활용도는 비교적 높은 편에 속하기 때문에 이벤트 타이머의 용도로 TSC가 사용될 수 있습니다. 이것 말고도 8254 PIT(Programmable Interval Timer)를 사용하기도 합니다만. (시간 정밀도를 비롯한 더 이상의 자세한 설명은 제가 잘 아는 분야가 아니라, 생략합니다.)

문제는 다중 코어 / 프로세서를 사용하는 SMP의 경우, 각각의 CPU 코어 마다 다른 TSC 값을 반환하는 데다가 전원관리로 인한 클럭의 변화 / 또는 BIOS에서 컨트롤하는 오버클럭 등으로 인해 그 격차가 더 크게 벌어지게 되는 것으로, 소위 TSC Drift라는 현상이 벌어지게 됩니다. 위에서 언급한 대로, Clocksource가 반환하는 값에 따라 각종 이벤트 호출 / 처리가 일어나기 때문에, 이러한 현상이 발생함으로 윈도우의 창을 이동할 수 없게 되는 현상이라던지, beep 음의 delay가 길어진다던지 하는 현상이 벌어지게 됩니다. 이벤트 타이머가 흐트러진다는 것이죠.

이러한 원인 때문에, TSC unstable이 나타날 수 있는 시스템은 멀티 코어 / 멀티 프로세서 기반의 시스템만으로 국한된다고 할 수 있습니다. 단일 프로세서에서는 나타나지 않는 현상이지요. (시스템 시계 속도가 달라지는 이야기와는 비슷하지만, 조금 다릅니다)

MS Windows의 경우, AMD 프로세서는 TSC를 일정 간격으로 동기화 시켜주는 드라이버를 Dual-core optimizer라는 이름으로, 이를 설치하게 함으로 해결하고 있습니다. (이렇게 하여, Windows API 대신 RDTSC 인스트럭션을 직접적으로 사용하는 프로그램에서 발생할 수 있는 성능 저하 문제를 해결합니다) 인텔 프로세서 역시 핫픽스 등이 있는 듯 하구요. 어찌되었건, 윈도우에서는 이러한 문제가 _거의_ 나타나지 않습니다.

어찌되었건 원인은 대충 이정도로 접어두고, 실전으로 들어가 봅시다.

1. 그냥 간단하게 줄여서, Clocksource tsc unstable 메시지 출력 후, 나타날 수 있는 "눈에 띄는" 현상은 다음과 같습니다:

* 벽시계(..wall clock)와 다르게, 시간이 늦게 가는 현상.
* PC 스피커로 나오는 beep 음의 길이가 평소와 달라진다. (길이가 길어진다던가)
* 시스템의 반응 속도가 현저하게 감소하는 현상.
* 키보드 키를 계속 누르고 있을 때 해당 문자가 반복되는 기능이 원활하게 동작하지 않을 수 있다.
* X Window system의 경우, 마우스 드래그를 통한 창 이동이 불가능 해 질 수 있다.
* TSC가 불안정하다고 판단하면, 필요에 따라 Clocksource를 커널이 자동적으로 변경하려고 시도하는데, 이 때 시스템이 얼어붙는 현상이 나타날 수 있다. (일시적인 freezing 이후 온전하게 다른 clocksource로 변경되는 경우에는, 다시 정상화 될 수 있다고 한다)

... 뭐 적어놓고 보니 시스템이 얼어붙는 것 빼고는 전부 이벤트 타이머로 인한 것.. 이라고 할 수 있겠군요. OTL.

2. 여하간, 이러한 문제를 해결하기 위해, 시스템 진단 절차를 다음과 같이 수행할 수 있습니다.

(1) dmesg로 Clocksource tsc unstable이 나타났는지 확인 (그 다음 재부팅을 하시던지는 상관없어요)
(2) sysfs에서 clocksource를 확인하도록 한다. 경로는 /sys/devices/system/clocksource/clocksource0 디렉토리 내의 current_clocksource 와 available_clocksource. 각각 현재의 클럭 소스와 가용 클럭 소스를 확인할 수 있습니다. cat으로 읽어보면 OK.
(3) available_clocksource가 어떤것이 있느냐에 따라 선택할 수 있는 해결책이 달라지게 됩니다.

3. 해결책에 대하여.

리 눅스 커널 메일링 리스트(LKML)의 2005년 11월 4일자로 올라온 Richard Brunner의 노트[2]를 보면, AMD CPU에서의 TSC Drift에 대해 자세하게 서술한 내용을 보실 수 있습니다. 그 내용을 바탕으로 해결책을 정리해보자면 다음과 같습니다.

(1) HPET : High-Precision Event Timer, 지금 현재 문제가 발생한 시스템이 ACPI 3.0을 지원하는 경우.

해 당 시스템이 ACPI 3.0을 온전하게 지원하는 메인보드 일 경우, HPET가 탑재되어 있을 것입니다. 이럴 경우에는, resolution도 높고, 다른 장치에 비해 오버헤드도 낮은 HPET를 선택하는 것이 가장 좋은 해결책입니다.

자신의 시스템이 HPET를 보유한 메인보드 일 경우, 그리고 커널에서 지원하는 경우, /system/devices/system/clocksource/clocksource0/available_clocksource 파일을 보시면 "hpet" 가 존재하게 됩니다.

자신의 메인보드가 HPET를 사용할 수 있지만(ACPI 3.0 대응), HPET가 위의 목록에서 나오지 않는 경우에는..
커널 설정의 Processor type and features 에서 "HPET Timer Support" 항목을 확인하시고, 이를 반영해주시면 됩니다.

부팅시 커널 옵션으로 clocksource=hpet 로 넘겨주면 됩니다. 그 밖에도, hpet=force (..개인적으로 권장하지는 않습니다) 가 있습니다.

안타깝게도 저의 경우는 ACPI 2.0을 간신히 지원하는 구닥다리 ATI IXP200 칩셋(네, 939소켓입니다 ㅠ)이라, HPET는 해당이 없습니다. vmware나 virtualbox도 이건 해당이 없겠네요.

(2) ACPI PM Timer

ACPI Power Management Timer는 대부분의 시스템에서 사용할 수 있습니다. [2]의 노트에서는, HPET의 차선책으로 ACPI PM Timer을 사용하는 것을 언급하고 있습니다. 커널 옵션 ... 의 위치는,

Power Management options ->
[*] ACPI (Advanced Configuration and Power Interface) Support ->
[*] Power Management Timer Support

로 하시면 되겠습니다.

이미 대부분의 배포판에서는 기본적으로 포함시키고 있을 것이므로, 부팅시 커널 옵션으로, clocksource=acpi_pm 을 추가하시면 됩니다.

(3) 어찌되었건 TSC를 사용하는 것을 피할려면

부팅시 커널 옵션으로, notsc 또는 clock=pmtmr 을 추가하도록 합니다. 가장 확실한 방법이긴 하군요. available_clocksource가 tsc와 jiffies 밖에 없는 경우는 좀 난감하겠습니다만.. 다만, notsc를 설정하게 되면 /proc/cpuinfo에서 클럭 수가 올바르게 나오지 않는 문제가 발생할 수 있으니 이를 염두해두시길 바랍니다.

이래저래 구글링 해보니, ACPI를 끄는 등의 과격한 행동을 권장하는 경우도 있긴 합니다만, 개인적으로는 추천하지는 않습니다. cpufreq를 계속 사용하실 것인지는 각자의 선택에 맡기도록 하구요..; BIOS에서 지원하는 프로파일 기반의 오버클럭 역시 마찬가지 되겠습니다.

이래저래 간단하게 써 보긴 했는데, 영 내용이 산만하네요. 이러한 문제를 마주치신 분들께는 안타까운 일이지만, 영어보다는 읽기 쉽구나... 라고 위안이라도 드려볼렵니다. OTUL

------
더 자세한 내용.

[1] TSC, Time Stamp Counter는 i586 (네, 펜티엄입니다)때 RDTSC 인스트럭션과 함께 들어가, CPU가 초기화되고 나서 이후의 tick 수를 알려주는 장치입니다. 이러한 TSC는 CPU의 전원 관리 시스템... 그러니까 다시 말하자면 클럭 조정(cool'n'quiet나, SpeedStep 같은..)이 들어가면서 P-state / C-state를 왔다갔다하게 되고, 이러면서 TSC가 일정하게 증가하지 않게 됩니다. 최근의 인텔 CPU의 경우 (코어2듀오나..) 클럭 변화에 상관없이 TSC값을 constant rate로 증가시키도록 만들었습니다. 자신의 cpu가 constant tsc를 지원하는지의 여부는, cat /proc/cpuinfo 하셔서 보이는 flags 값 중에 constant_tsc가 있는지 확인하시면 됩니다.

[2] 2005년도에 Richard Brunner가 AMD CPU의 TSC Drift와 해결책에 대해 자세하게 서술한 노트가 있습니다. 다음의 링크를 참조하시면, 해결책과, 자세한 내용을 알 수 있습니다. http://lkml.org/lkml/2005/11/4/173