커널 2.6.24와 CPU Idle PM

2.6.24 커널의 전원 관리에 CPU Idle PM이 추가되었다.

idle 시 CPU의 전원 관리를 포괄해서 관리하는 모듈인데 뭐 자세한 건 잘 모르겠고,
이 모듈이 추가되면서 2.6.23 커널까지 사용자가 ACPI C0~C4(또는 그 이상) State를 임의로 조작할 수 있었던 것이
일단 불가능해졌다.

단순히 C State를 파라미터로 쓰는 게 아니라 복잡적이고 종합적인 방법으로 바꿨기 때문이라나...
자세한 건 역시 잘 모른다.

아무튼 불편해진 이들이 두 부류가 나타났는데,

첫 번째가 vmware의 느린 속도 때문에 /sys/modules/processor/parameters/max_cstates에다 1를 넣어서 쓰던 이들이고,

다음으로 CPU 고주파 노이즈 때문에 max_cstate를 2로 잡아서 쓰던 나같은 이들이다.

Core 1(또는 2) Duo의 버그랄까 불량이랄까 설계상 미스랄까, idle에 진입하여 ACPI C3 이상으로 전원 관리 단계가 올라가면,
코어 안의 캐피시터였든가 어느 부품이 귀를 찌르고 머리를 어지럽히는 고주파를 발생하는 사례가 적잖히 있다.

OS X와 윈도즈에서도 각각 C State와 관련해서 Work-Round 수준의 처방이 있고 (근원적인 해결법은 고주파가 나지 않는 부품으로 교체하는 것뿐이다)
리눅스에서도 max_cstate를 모듈 옵션 내지 커널 파라미터로 넣거나 직접 echo로 값을 바꿔가며 쓰면서 해결해왔는데
2.6.24부터 상황이 바뀐 것이다.

/sys/modules/processor 디렉터리에 가보면 이전과는 전혀 다른 파일, 파일 내용이 들어 있다.

마찬가지로 vmware와 max_cstates로 검색을 해보면 관련 정보를 얻을 수 있다. vmware의 버그라고 원망하는 말을 볼 수도 있었다.

아무튼 다 생략하고 현재 이 문제는 진행 중인데, 임시적인 해결책은 1) CPU Idle PM을 선택하지 않고선 예전대로 max_cstates 값을
사용자가 조작하도록 하는 것이다.

마치 phc 패치를 써서 코어의 입력 전압을 바꾸던 대상이

Intel Enhanced SpeedStep 모듈이었다가 ACPI Processor P-States driver 모듈로 바뀌어 가던
도중의 상황과 유사해 보인다.

뭐 랩톱에서 고주파가 나는 사람이 나 하나가 아닌 이상, 조만간 CPU Idle PM을 쓰면서 고주파를 잡을 수 있는 방법이 나오리라
예상한다. 안 나오면 뭐 니눅스 엎어 버리고 OS X나 써버려야지.

그떄까진 2.6.23 커널을 쓰거나 CPU Idle PM을 당분간 쓰지 않으면서 기다려볼 수밖에 없다.

냠... 오덕인 게 죈가... .신발....

2) 데비안 Unstable을 기준으로 ACPI Processor를 커널로 삽입하고선 lilo 등에서 커널 파라미터로

processor.max_cstate=2

를 집어 넣는 방법이다.

http://www.thinkwiki.org/wiki/Talk:Problem_with_high_pitch_noises

이 위키에 보면 고주파를 잡는 여러 방법이 소개되어 있는데, 내가 깐 데비안은 processor를 모듈로 했을 경우 커널 파라미터가
저~언혀 효과가 없었다. modprobe.d 디렉터리 아래에 옵션을 추가하는 방법도 대충 시도해 봤는데 쓸모가 없었고,

위에 이미 적었지만 Processor를 커널에 삽입하였어도

max_cstate=2 대신 processor.max_cstate=2를 lilo.conf에 추가해야 했다.

참고로, 이미 요즘 나오는 2.6.24 커널 소스에는 패치가 되어 있을 텐데, max_cstate를 다시 표시하는 패치는 다음과 같다.

 drivers/acpi/processor_idle.c |    4 ++++
 1 file changed, 4 insertions(+)
 
diff -puN drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case
+++ a/drivers/acpi/processor_idle.c
@@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
 #define PM_TIMER_TICKS_TO_US(p)		(((p) * 1000)/(PM_TIMER_FREQUENCY/1000))
 
 static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
+#ifdef CONFIG_CPU_IDLE
 module_param(max_cstate, uint, 0000);
+#else
+module_param(max_cstate, uint, 0644);
+#endif
 static unsigned int nocst __read_mostly;
 module_param(nocst, uint, 0000);
 
_

참고 링크 : http://bugzilla.kernel.org/attachment.cgi?id=14330&action=view

* CPU Idle PM 선택을 해제하지 않고 이 패치를 적용하면 max_cstates 파라미터 파일이 다시 나타나지만
echo "2" > max_cstates 명령을 실행하여 파라미터를 변경해도 전혀 효과가 없다.

즉, 고주파가 계속 나왔다.

--------------------------
정리 ) max_cstates 패치 적용 여부를 확인하고 안 되었으면 패치를 한다.

CPU Idle PM 옵션을 고르지 않고서 예전대로 /sys/modules/processor/max_cstates 파일을 건드린다.
웹 검색으로 얻은 정보지만 직접 확인은 하지 못 했다. 아래에 나온 Processor 모듈을 커널 안에 삽입하는
방법을 먼저 시도해 봐서 효과를 봤기 때문에 더 이상의 삽질을 중단했기 때문이다.
또한 이 경우 max_cstates 값을 커널 파라미터 / 모듈 옵션을로 집어넣는 방법을 쓸 수도 있는데 마찬가지로 확인되지 않았다.

또는 CPU Idle PM 옵션을 쓰면서 대신 Processor 옵션을 모듈 대신 커널 안에 삽입하고 커널 파라미터에
processor.max_cstate=2 (데비안 Unstable 기준)를 적어 넣는다. 모듈 아규먼트로 적는 법은 확인해보지 않았다.
그리고 이때는 max_cstates 파일은 무용지물.

----------------------------
사용한 검색어 :
pitch noise
max_cstates 2.6.24
whining noise
등등으로 구글과 젠투 포럼, 우분투 포럼을 뒤졌음