한성 gboard 8.9의 기술적 문제

By SeukWon Kang

October 27, 2013

한성 gboard 8.9를 쓰다보면 이상하게도 H/W 스펙에 비해서 너무 느리다는 느낌을 받는 경우가 많습니다.

프로그램 전환간에 랙이 생기는 경우도 많고 게임을(심슨) 하다가도 터치에 반응하는 스크롤이 멈짓 멈짓하는 것을 많이 느낄 수 있지요.

처음에는 백그라운드 프로세스가 너무 많이 있나 싶어서 거의 대부분을 제거 해봤습니다.

커스텀 펌웨어도 여러가지로 바뀌 봤구요.

하지만 쓰면 쓸수록 이문제는 S/W 문제 라기보다는 H/W 문제인것 같은 생각이 들었습니다.

프로세스 모니터를 사용해서 cpu 사용량을 보면 rknand_buffer 프로세스가 비정상적으로 cpu를 많이 사용하는 것을 볼 수 있었습니다.

아마 내장 flash disk 가 너무 느려서 그런가보다 하고 백그라운드에서 disk access를 할 것으로 생각되는 프로세스들을 죽이고 uninstall 했습니다..

( search 관련 프로세스들이 disk를 계속 모니터링합니다. 겔러리 도 그렇구요. 새 파일이 생성되면 바로 반영하기 위해서지요. )

좀 나아지긴 하지만 그래도 여전히 버벅이더군요.

( ext4 로 파일 시스템을 바꿔볼까 하는 생각도 잠깐 했지만 , 시스템 파티션은 이미 ext4입니다.)

그래서 아예 리눅스 커널 부트 로그를 들여다 봤습니다. ^^

/proc/last_log 파일입니다.

파일내용을 보면서 알게된 몇가지 사실을 적습니다.

커널자체는 정상적인 smp preemptive 커널입니다. 문제가 될 소지는 별로 없지요.

멀티 프로세서 지원 smp, 강제 스케줄링가능 preemptive 기능도 다 최신 기능입니다.

총 ram 2048Mbyte중 시스템이 예약/확보 하는 양은

memory reserve: Memory(base:0x76800000 size:512M) reserved for <ump buf>

memory reserve: Memory(base:0x71800000 size:80M) reserved for <ion>

memory reserve: Memory(base:0x6fd00000 size:27M) reserved for <fb0 buf>

memory reserve: Memory(base:0x6f700000 size:6M) reserved for <camera_ipp_mem>

memory reserve: Total reserved 625M

입니다.

512M ump buf는 아마도 video ram 영역일 듯 합니다. 1920x1200의 화면을 3d가속하기위해서 최소한 이정도는 필요하겠지요.

ion은 뭔지 모르겠고 fb0는 화면 표시용 버퍼 입니다. 1920x1200x4 byte의 3배 정도를 확보하는군요. 더블 버퍼링이나 트리플 버퍼링하기 위한 공간일듯 합니다..

camera_ipp_mem는 딱봐도 카메라용 io buf같습니다.

그래서 총 625Mbyte가 시스템/io를 위해서 예약 됩니다.

이 공간은 OS/안드로이드 를 위한 공간이 포함되어 있지 않습니다.

즉 OS가 추가로 메모리를 더 사용하게 될테니 부팅후 2048Mbyte 의 ram 중에서 1000여 Mbyte의 여유 메모리가 남는 것은 지극히 정상적입니다.

계속 보면 ddr3 controller를 초기화 하는 것도 보이고 cpu cache를 초기화 하는 것도 보입니다.

<6>[ 0.000000] l2x0: 16 ways, CACHE_ID 0x4100c0c8, AUX_CTRL 0x76050001, Cache size: 524288 B

cpu cache 는 512k 인것 같군요.

그 다음에 놀라운 사실을 알수 있는데

DDR DEBUG: Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Total Capability=2048MB

DDR DEBUG: init success!!! freq=300MHz

을 보면

메모리 io bit가 32bit 밖에 안된다는 사실을 알 수 있습니다.

뭐가 문제지? 하고 생각하는 사람을 위해서 잠시 설명하면

우리가 사용하는 pc는 메모리 버스 넓이가 64x2=128 bit이며 이것은 gpu가 사용하는 video 대역을 제외하고 란 점입니다.

한성 gboard 8.9는 cpu+gpu가 사용할 메모리와의 통신 을 위한 길의 넓이가 32bit 란이야기이며

이 좁은 길을 통해서 1.6Ghzx4의 cpu와 mali400 gpu가 작업을 해야 한다는 이야기입니다.

그 메모리 버스를 통해서 1920x1200의 그래픽 처리와 4개의 cpu가 실행할 프로그램/데이터가 오가야 한다는 거지요.

2013년에 시장에 팔리는 vga중 가장 하위 모델이라고 해도 64bit 정도의 메모리 버스 크기를 가지고 있으며 와 별도로 cpu는 128bit 의 cpu전용의 버스를 가지고 있습니다.

참고로 ipad는 128bit의 메모리버스(cpu/gpu공용의) 를 가지고 있습니다.

그리고 바로 그다음 라인은

ddr3 ram의 클럭이 300mhz로 초기화 된다는 것을 알 수 있습니다.

메모리 전송속도는 32bit x 300mhz x 2 = 2400Mbyte /sec 정도의 전송률을 보이겠군요.

다행히 뒤에 가면

<6>[ 6.067451] ddrfreq: verion 2.4 20130427

<6>[ 6.067519] ddrfreq: normal 528MHz video 0MHz dualview 0MHz idle 0MHz suspend 198MHz reboot 300MHz

<6>[ 6.069573] ddrfreq: change freq to 528 MHz when normal

으로 초기화가 끝나면 528Mhz로 상승합니다.

그래도 cpu+gpu를 위한 메모리 대역폭은

32bit(4byte) x 528Hhz x 2(ddr3) = 4.125Gbyte /sec 정도 입니다.

참고로 xbox 360 과 ps3 의 메모리 전송률 입니다.

비록 발매된 시기는 많이 다르지만 (xbox 360, ps3는 2005년 경 ) xbox 360 , ps3 , gboard 8.9 모두 full hd의 화면을 제어해야 한다는 점에서 보면 gboard의 느린 속도의 문제는 memory sub system에 있었던 것 같습니다.

ps) 써놓고 보니 한성의 문제인 것 처럼 보이는데.. 본문에 제가 쓴 글이 맞다면 문제의 원인은 한성에 있는 것이 아니고 rk3188 soc 에 있는 것이며, 다른 중국산 soc들이 더 낫다는 보장도 없습니다. 그리고 현재 상태에서도 웹서핑하고, 글/만화/동영상보고 하는 데에는 아무런 문제가 없는 성능입니다. 또 메모리 버스를 넓히면 보드 설계도 힘들어지고 제작 단가도 올라가니 rockchip사에서도 가격적인 부분에서 고민하다 내린 결정 일 것입니다. ( 그러하기 때문에 후속 칩에서도 크게는 개선 되지 않을 가능성도 있습니다. ) 위키피디아에 의하면 http://en.wikipedia.org/wiki/Rockchip 후속 칩인 RK32xx는 듀얼 채널 이라고 하니 64bit 메모리 버스를 사용하겠군요.