듀얼 코어이니 역시 듀얼의 위력을 제대로 발휘하도록 해야겠지요?
VMware 5.5에서의 가장 큰 변화라면 역시 SMP지원입니다.
즉, 기존의 5.0까지는 듀얼 코어를 써도 VM(가상시스템)이 single-thread로 동작을 했습니다.
CPU하나만 열심히 쓰던 5.0에서 5.5부터는 CPU를 2개 까지 지원합니다.
멀티 쓰레드로 동작해서 기존보다 빠른 속도를 즐길수 있게 되었습니다.
아직 RC2이고 정식 릴리즈는 아니라서 몇몇 버그는 어쩔수 없이 직접 처리를 해야되더군요.
지금부터 그 2번째 이야기로 돌입합니다.
일단 5.0에서 5.5로의 업그래이드는 순조롭게 되었습니다.
VM의 설정에서 CPU갯수란이 생긴것이 반갑더군요. VMware 0.1버젼에서 지금 까지오면서 가장 기다려왔던 기능중 하나라고 생각됩니다. 5.0->6.0으로 바꿔도 될만하다고 생각했는데, 쉬웠던 모양입니다.(웃음)
그렇게 해서 띄우게 되었는데, 정말로 듀얼로 뜨더군요. 흠...기분이 묘하더군요.
그렇게 해서 아무런 변경 없이 X-windows까지 떴습니다. 여기서 문제가 생기더군요.
키보드를 타이핑하는데, 이게 한번 눌렀는데 같은 글자가 적게는 1번 많게는 7자까지 찍히더군요.
이거 또 시간 문제구나...라고 생각이 들더군요. 아니나 다를까 vmdevelop포럼에서 검색해보니 다수의 사용자들이 이 문제를 겪고 있더라고요. keyboard chattering문제는 5.0에서도 TSC문제로 이미 예상을 했었습니다. 어떤 사람들은 linux커널에 notsc옵션을 줘서 해결을 했다고 하더군요.
저도 해보려고 했으나...이놈의 커널이 CPU optimize를 486이상으로 해서 notsc가 안되더군요. 결국 커널을 다시 컴파일해서 notsc가 먹히도록 했습니다.
그렇게 잘 쓰게될줄 알았습니다...
그러나..
껐다 켰다 해보니 빈번히 IO-APIC에서 timer를 못찾는 문제가 발생하였습니다. 즉, IO-APIC에서 8254 timer를 찾지 못했다는 것인데...
사실 IO-APIC을 사용함으로써 실제로 성능 향상을 느낄 만큼의 interrupt가 발생하는것이 아니라면 굳이 쓸 필요가 없다고 생각해서 차라리 noapic으로 설정해서 쓰는것이 빠를듯했습니다.
결국 noapic으로 해서 써보니 이전에 IO-APIC으로 썼던때보다 속도가 훨씬 빨라졌습니다.
어차피 어플리케이션으로 돌아가는 VM이니 IO-APIC이나 XT-PIC이나 그게그거 아니겠습니까? 둘다 메모리 전송인데...
만약에 실제 H/W라면 약간(?)의 차이가 있을지 모르겠지만요. 어차피 옵테론이라면 XT-PIC나 IO-APIC이나 MSI를 쓰더라도 전부 하이퍼트랜스포트로 전송될것이니깐 별 차이가 없을지도 모르겠네요.
일단 noapic로 XT-PIC를 쓰게 만들고 키보드 문제는 clock=pit로 해결하였습니다. 이렇게 만들고보니 기존에 IO-APIC때문에 vmware에서 쓰레드간 TSC싱크로를 하는것때문에 발생하던 손실이 거의 복구 되었습니다.
커널 컴파일(make clean; time make -j3)로 벤치마크를 하자면
1. apic, tsc sync = 17min
2. noapic, notsc = 15min
3. noapic, clock=pit = 4min
어떻습니까? 엄청난 속도 향상이 보이시나요? 후후후
CPU간의 동기를 맞추는 문제가 단순히 키보드가 버벅거리는 문제는 아닌것이였습니다. 근본적인 원인을 찾아서 해결하고보니 기분이 좋네요.
그러고보니 이전에 VMware5.0을 썼을때 vmware에서 IO-APIC을 안쓰고 굳이 XT-PIC모드로 동작하던것이 이해가 되네요. 실재 H/W에서는 이런 문제가 있을리 없으니 VMware5.5을 쓸때만 이렇게 쓰면 될것 같네요.
이상 아슈아리아였습니다.
ps. 아직 vmware develop forum에 올리지도 않았습니다. 따끈따끈~ 합니다.
[이 게시물은 최고관리자님에 의해 2009-02-02 16:55:52 gonan에서 이동 됨]
[이 게시물은 관리자님에 의해 2009-06-09 16:09:56 review에서 이동 됨]
짧은글 일수록 신중하게.